A table opened at two places?? 1

[TheBlainer]

Hi
I have a form with a listbox that contains a SQL statement. In the init of the form, there's the code

Thisform.lsttHERMOS.RowSourceType = 3
SELECT 107
USE N:\APPS\PAL_NOVA SHARED
thisform.lstthermos.RowSource = "SELECT NOM FROM " + DBF(107) + " INTO CURSOR mylist"

THISFORM.LSTthermos.Requery
THISFORM.lstthermos.SetFocus

I used the debugger and I saw that when I affect the rowsource to the lstthermos, the table is also stocked in the dbf(4), so it's in the DBF(107) and DBF(4).
Why 4? 1, 2 and 3 aren't used...

So I wonder if someone know why it's doing that, because it wouldn't be the first time this kind of problem happen to me.
Thanks

TheBlainer

 

[Mike Lewis]

This simply means that the table is open in two separate work areas. There's nothing wrong with that. In this case, it probably happens because you are opening the table explicitly (with USE), and also the SELECT statement is opening it behind the scenes.

However, I have to say that your code does not follow accepted practices. You should never specify work areas by number, and you should never open tables in explicit work areas. In other words, rather than this:

SELECT 107
USE N:\APPS\PAL_NOVA SHARED

You should do this:

USE N:\APPS\PAL_NOVA IN 0 SHARED

and thereafter simply refer to the table by its alias, which is PAL_NOVA.

In fact, in the code you have shown, there's no need to USE the table at all. The SELECT statement will open it if it needs it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TheBlainer]

First : Thanks Mike for your reply

Second : indeed I didn't have to USE the table. I only put the file in the select and there's no more problem with workaeras.

Third : When I first learnt VFP longtime ago, we showed me this way of using table and I tought that it was the right way to do it. I was finding weird the fact that we had to always use numbers to select table and i was thinking that names would be better than numbers.
I created a frmtest to try to code with the "right" way of playing with tables. For the moment, it's working fine and I prefer this way.

Now, I have to create new forms in my application that I have to maintain. So I will put what I learnt in it and see if it works great.

Thanks again Mike

TheBlainer

 

[Olaf Doschke]

Towards the other detail question - why areas 1,2,3 aren't used:

If your sql would be more complex I'd say 1,2,3 where used temporarily during execution of the sql and the result landed in workarea 4. It might jsut be random. If you do sql you can't decide whare foxpro creates what temp or final result.

And that's also another good reason for not working with workarea numbers. If you rely somthing is open in a certain workarea number, you may get into trouble. It's not that sql will use any workarea that is already in use and close what is open, but it will determine workarea use as you should, by the principle of the "next" free workarea, which you can adress as 0 always. It's random but reliably unused and it will not always be the lowest unused workarea.

The workarea numbers once where useful, when there where only 10 of them. As an artifact of that you still can SELECT a to j as workareas 1-10, but today you rather rely on the alias names instead.

Bye, Olaf.

 

[Mike Lewis]

You're welcome. It's good that you are now doing it the right way.

I don't know how long ago you were told to use numbered work areas, but it's never been the right way to do it in VFP. Names work areas were introduced in dBASE III Plus (around 1984, I think), and have been used ever since.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TheBlainer]

I want to mention that this program is old and was first made in dBASE 4 and was transfered to foxpro 2 later.
It should be because of that if it was made this way and has been passed over the years.

TheBlainer