Work areas and database base tables

Yes, the main tables are opened in other work areas when you USE a view.

That's why you should always USE freetable IN 0 or do a SELECT 0 before you
do a just plain USE freetable (or any table/view for that matter).
--
Fred
Microsoft Visual FoxPro MVP

Post by CM
When I open a database and use a view in a given work area, are the base
tables open in other work areas?
I make changes to fields in the view and those changes get pushed back to
the base tables. I'm concerned that, if I open a free table in a work area
that was occupied by a base table, my changes will not longer be made in that
base table.
Thanks for any help,
CM

2004-10-21 19:03:03 UTC

Thank you. One other question though...

If I use these statements to open free tables, how do I determine which work
area they end up in? Usually, my routines involve replacing fields in the
view with fields in the free table(s) - such as REPLACE A.FIELD1 WITH
G.FIELD5 - where A is the work area containing my view and G is the work area
containing the free table.

Thanks again,

CM.

Post by Fred Taylor
Yes, the main tables are opened in other work areas when you USE a view.
That's why you should always USE freetable IN 0 or do a SELECT 0 before you
do a just plain USE freetable (or any table/view for that matter).
--
Fred
Microsoft Visual FoxPro MVP

Anders Altberg

2004-10-21 20:04:41 UTC

Don't worry about it. VFP handles updating the base table of a view
automatically. the base table is opened when you open the the view, USE
view, you can open the Data Session window see what's open. You can close
the base table if you like. In a tablebuffered view you can Insert, Delete
or Update data till you call TableUpdate(.T.). Only then is the base table
opened again - and you can close it again if you like. A
REQUERY('viewname') will also open the base table.
A query will usually open the base tables with entirely new aliases.
Don't refer to open tables by workarea letters or numbers. Refer to open
tables by their alias. You can check if an alias is already used; if not
open the table with the alias you want
IF NOT USED('Customers')
USE Customers AGAIN IN 0 Alias Customers
Endif
* SELECT Customers
Now you have the table opened with an alias you're sure of. The workarea
letter or number is immaterial. For all you know the same table can already
be open several times under other aliases. It doesn't matter.
-Anders

Post by CM
Thank you. One other question though...
If I use these statements to open free tables, how do I determine which work
area they end up in? Usually, my routines involve replacing fields in the
view with fields in the free table(s) - such as REPLACE A.FIELD1 WITH
G.FIELD5 - where A is the work area containing my view and G is the work area
containing the free table.
Thanks again,
CM.

Post by CM
that
base table.
Thanks for any help,
CM

2004-10-22 17:31:01 UTC

Thank you. Very helpful.

Actually, I'm familiar with the data session and so forth, but my concern
was with opening a free table in a work area that may already by holding one
of the base tables - causing it to be closed and, possibly, not receive
updates I make to the view. I've set TableUpdate(.T.) for the vew. Thanks
for the quick lesson on using aliases. This will make my work much easier.

CM.

Post by Anders Altberg
Don't worry about it. VFP handles updating the base table of a view
automatically. the base table is opened when you open the the view, USE
view, you can open the Data Session window see what's open. You can close
the base table if you like. In a tablebuffered view you can Insert, Delete
or Update data till you call TableUpdate(.T.). Only then is the base table
opened again - and you can close it again if you like. A
REQUERY('viewname') will also open the base table.
A query will usually open the base tables with entirely new aliases.
Don't refer to open tables by workarea letters or numbers. Refer to open
tables by their alias. You can check if an alias is already used; if not
open the table with the alias you want
IF NOT USED('Customers')
USE Customers AGAIN IN 0 Alias Customers
Endif
* SELECT Customers
Now you have the table opened with an alias you're sure of. The workarea
letter or number is immaterial. For all you know the same table can already
be open several times under other aliases. It doesn't matter.
-Anders

Post by CM
Thank you. One other question though...
If I use these statements to open free tables, how do I determine which

work

Post by CM
area they end up in? Usually, my routines involve replacing fields in the
view with fields in the free table(s) - such as REPLACE A.FIELD1 WITH
G.FIELD5 - where A is the work area containing my view and G is the work

area

Post by CM
containing the free table.
Thanks again,
CM.

Post by Fred Taylor
Yes, the main tables are opened in other work areas when you USE a view.
That's why you should always USE freetable IN 0 or do a SELECT 0 before

you

Post by Fred Taylor
do a just plain USE freetable (or any table/view for that matter).
--
Fred
Microsoft Visual FoxPro MVP

Post by CM
When I open a database and use a view in a given work area, are the

base

Post by CM
tables open in other work areas?
I make changes to fields in the view and those changes get pushed back

Post by CM
the base tables. I'm concerned that, if I open a free table in a work area
that was occupied by a base table, my changes will not longer be made

Post by CM
that
base table.
Thanks for any help,
CM

Cindy Winegarden

2004-10-21 20:05:36 UTC

Hi CM,

Personally, I'd never trust referring to work areas by either their number
or the single letters - to be safe you should always us the alias of the
table/cursor/view. Also, make use of the In clause of the Replace statement
(see docs):

Replace Orders.ShipToAddress With Customers.ShipToAddress In Orders
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP

Post by Fred Taylor
That's why you should always USE freetable IN 0 or do a SELECT 0 before you
do a just plain USE freetable (or any table/view for that matter).

If I use these statements to open free tables, how do I determine which work
area they end up in? Usually, my routines involve replacing fields in the
view with fields in the free table(s) - such as REPLACE A.FIELD1 WITH
G.FIELD5 - where A is the work area containing my view and G is the work area
containing the free table.

2004-10-22 17:35:16 UTC

Thank you very much. I've inherited systems that use work area references
instead of aliases, so this is what I'm used to. The alias approach looks
like it will be much easier to work with and maintain.

I'll look up the info you referenced.

Thanks again,

CM

Post by Cindy Winegarden
Hi CM,
Personally, I'd never trust referring to work areas by either their number
or the single letters - to be safe you should always us the alias of the
table/cursor/view. Also, make use of the In clause of the Replace statement
Replace Orders.ShipToAddress With Customers.ShipToAddress In Orders
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP

Post by Fred Taylor
That's why you should always USE freetable IN 0 or do a SELECT 0 before you
do a just plain USE freetable (or any table/view for that matter).

Jeroen van Kalken

2004-10-21 22:34:53 UTC

On Thu, 21 Oct 2004 12:03:03 -0700, "CM"

Why would you do that? The whole point of a view is that you get an
abstract view of the underlying tables (and not the tables
themselves). All updating should be done through the view.
This also gives you the oppertunity to later change the underlying
tables, either in structure, location or type (e.g. move to SQL)
without the need to change your program.

2004-10-22 17:35:17 UTC

Thanks. Actually, I'm not trying to work directly with the base tables. I
was concerned that opening free tables in work areas already used by base
tables would result in closing those base tables and preventing changes I
make to the view from getting back to the proper base tables.

Very helpful. Thanks again,

CM.

Post by Jeroen van Kalken
On Thu, 21 Oct 2004 12:03:03 -0700, "CM"

Jack Jackson

2004-10-21 23:05:02 UTC

Don't refer to workareas by number or by single letter, use an alias
instead (USE xxx IN 0 ALIAS abc) and always refer to the table using
the alias.

On Thu, 21 Oct 2004 12:03:03 -0700, "CM"

2004-10-22 17:37:02 UTC