>>>>Thanks,
>>>Hi Bill,
>>>
>>>Will

>>>lcdbc = CURSORGETPROP('Database')
>>>llisfree = EMPTY(lcdbc)

work?
>>
>>Actually, this will only work after opening the table, which I think is what he istrying to avoid.
>>
>>William, you can get this information from the dbf file by opening it with low level functions, and checking the value of the right byte. Unfortunately, the dbc location comes after the field records, so its location varies depending on how many fields the table has. But here's how to calculate what byte to look at:
>>
>>31 + 32*nFields + 2
>>
>>So if your table has 10 fields, your dbc location (or lack of) can be found beginning at byte 31+320+2, or 353. If the table is free, Byte 354 will contain a 0 (0x00) otherwise it will contain the relative path to the database.
>>
>>lhFile = FOPEN("C:\table1.dbf")
>>=FSEEK(lhFile, 353)
>>ldFreeByte = FREAD(lhFile, 1)
>>
>>IF ASC(ldFreeByte) = 0
>>* Table is Free
>>ENDIF
>
>Hi Erik (and I'm forwarding this to Ed too, you suggested something similar),
>
>The only problem I have with this method as opposed to the other one is the overhead involved (compared to my solution). In reality, either way you're "opening" the table. In my case it's a high level access, as opposed to low level here.

The thought here is that the 'high level' open may cause an error - a problem with the backlink, for example. None of the trigger activity for any automatically connected resources occur - LLF won't try to open the DBC, or an associated FPT or CDX.

The code fragment I wrote isn't necessary if you know you can already open the table without an error for a .DBC; low-level I/O may be useful in 'detatching' a problematic/corrupted .CDX, or fixing up the backlink when you've moved the table. It was more to show what needed to be checked in a way that didn't have all the 'side effects' of a high-level action.