Hi JWilsonny,
checking if a file (table) can be found with FILE() can give you a hint, if you know where the table should be found, yes. FILE() will also find tables included in the exe, so you won't have a problem with these, too.
If your main concern is network fails, you could check IF FILE(DBC()) before a select. FILE(DBF(ALIAS())) would check if the current workarea's table is found on disk. But next to FILE() returning .T., the network could fail and you'd still get the open dialog. Okay, that's quite a seldom situation.
Still it won't work in every situation. Think about the example Mike Lewis gave:
SELECT 0
BROWSE
a) What File must be checked with FILE()?
b) Even if you know what you wanted to BROWSE (or select from etc.) if it's found with FILE() you'd still not know, if it's found by BROWSE (is it the selected workarea?) or an SQL Select (fine if the file is there, but if it isn't used and isn't part of the set database, it's not found by a SQL-SELECT).
example:
database1 contains table1 and table2,
database2 contains table3 and table4,
Both databases are in the same folder.
Code:
OPEN DATABASE ...database1
OPEN DATABASE ...database2
CLOSE TABLES ALL
SET DATABASE TO database1
CD (justpath(DBC()))
IF FILE("table3")
SELECT * FROM table3 INTO CURSOR cursor3
ENDIF
This won't work, although FILE("table3") signals "Okay" for the SELECT.
On the other hand, if database1 and database 2 are in 2 different folders:
Code:
OPEN DATABASE ...database1
OPEN DATABASE ...database2
CLOSE TABLES ALL
SET DATABASE TO database2
USE table3 IN 0
SET DATABASE TO database1
CD (justpath(DBC()))
IF FILE("table3")
SELECT * FROM table3 INTO CURSOR cursor3
ENDIF
This time the SQL would have worked, because table3 is open, but FILE() didn't find it, as database1 is in a different folder, not containing table3.
It may not be impossible but gives much overhead to determine if an SQL-Command or anything concerning a table will work based on the current set database, current datasession, used aliases and active workarea. At least there is no "one fits all" solution. Some commands need an (any) table in the active workarea (BROWSE, USE), others can open tables that aren't used so far (SQL).
As Mike Lewis said, you should use certain programming pragmas as:
IF !USED(cAlias)
USE cDatabase!cAlias IN 0
ENDIF
SELECT .. FROM cDatabase!cTable ...
Not using tables with different aliases if not needed (for example only with AGAIN).
Using the IN Clause:
REPLACE ... IN "Alias"
SKIP ... IN "Alias"
ZAP IN "Alias"
etc.
INDBC(), DBC(), DBF(), DBGetProp(), AUSED() and ASSERT may also be helpful, if you want to check things before certain commands, for example comparing DBF("Alias") with DBGetProp("Alias","TABLE","Path"), but if the network fails during a select you're as helpless as without a pre check. And this checks can also have errors which could make your app too cautious, not working in situations it would indeed work...
Bye, Olaf.