FoxPro Setup - Dbc and Free Tables

Author

Dbc and Free Tables

deciacco

2005-09-01, 9:25 am

Using the bang operator solves the problem of resolving the reference
to a table in a database. But when I use a free table in a select
statement that has the same name as a table in the database, fox thinks
I want the table in the database instead of the free table. What can I
do to fix this? How can I incapsulate the free tables so I can keep
them separate from the
database tables?

Thank you.

Rick Bean

2005-09-01, 9:25 am

One way is to close the database before you USE the free table. VFP always looks
for the free table before opening the one in the database. You could also
qualify the USE with the path to the table - they both can't be in the same
directory!

Rick

"deciacco" < eugenio_cilento@hotm
ail.com> wrote in message
news:1125581879.824768.198100@g47g2000cwa.googlegroups.com...
> Using the bang operator solves the problem of resolving the reference
> to a table in a database. But when I use a free table in a select
> statement that has the same name as a table in the database, fox thinks
> I want the table in the database instead of the free table. What can I
> do to fix this? How can I incapsulate the free tables so I can keep
> them separate from the
> database tables?
>
> Thank you.
>

deciacco

2005-09-01, 11:25 am

Thanks for the reply...

No they are not in the same directory, but I was trying to avoid having
to qulify the path in the USE. I have several objects that run select
statements against dbase tables and they rely on the path being set so
the tables can be found. I would have to change all the sql statements
to use aliases assigned in a USE statement, and I would have to issue
the "USE" statement prior to running the sql. I was hoping I could
avoid this.

I would like to use this separate database to house metadata for the
objects and later on expand it to include data from the old dbase
tables with a new more flexible db design. What would be ideal is to
use a database and put the old tables in it, but I can't do this
because the old tables house production data. (They are dev tables
copied with a batch command from production) If I put them in a
database I wouldn't be able to just copy the production tables over,
but I would have to write a routine to import data. Again, I was hoping
to avoid this. I'm fairly new to fox so I'm might just not be setting
things up right. Until now it was easy to just set the path and issue
my selects. I could use different names for the new tables and keep
them in the same dir as the old tables and prefix the ones that would
otherwise have the same name as the old tables. I don't like this
option as its not nice a clean and doesn't seem like a propper
solution.

Thanks.

Rush Strong

2005-09-01, 11:25 am

You might try:

USE MyTable ALIAS FreeMyTable

- Rush

"deciacco" < eugenio_cilento@hotm
ail.com> wrote in message
news:1125587439.038026.51040@g47g2000cwa.googlegroups.com...
> Thanks for the reply...
>
> No they are not in the same directory, but I was trying to avoid having
> to qulify the path in the USE. I have several objects that run select
> statements against dbase tables and they rely on the path being set so
> the tables can be found. I would have to change all the sql statements
> to use aliases assigned in a USE statement, and I would have to issue
> the "USE" statement prior to running the sql. I was hoping I could
> avoid this.
>
> I would like to use this separate database to house metadata for the
> objects and later on expand it to include data from the old dbase
> tables with a new more flexible db design. What would be ideal is to
> use a database and put the old tables in it, but I can't do this
> because the old tables house production data. (They are dev tables
> copied with a batch command from production) If I put them in a
> database I wouldn't be able to just copy the production tables over,
> but I would have to write a routine to import data. Again, I was hoping
> to avoid this. I'm fairly new to fox so I'm might just not be setting
> things up right. Until now it was easy to just set the path and issue
> my selects. I could use different names for the new tables and keep
> them in the same dir as the old tables and prefix the ones that would
> otherwise have the same name as the old tables. I don't like this
> option as its not nice a clean and doesn't seem like a propper
> solution.
>
> Thanks.
>

deciacco

2005-09-02, 3:29 am

Thank you both for the help.
I ended up just using the USE statement to open all my tables prior to
running the sql statements.

Sponsored Links