Thanks, Sergey. I would not have thought of this. I will be interested to see if this solves the problem of the OS thinking the DBC is still open - I see that lnFH is the file handle for the table. i guess I am not clear about how the DBC opens and closes relative to how the table opens and closes. I'll let you know as soon as i test this.

>You can use FOPEN.

lcDbfName = "h:\mytables\mytable.dbf"
>lnFH = FOPEN(lcDbfName, 12)
>IF lnFH > 0
>  =FCLOSE(lnFH)
>  * Ok to work with the table
>ELSE
>  * The table is open somewhere else
>ENDIF
>

>
>>I'm writing a little utility to data drive the backup of folders by zipping them (mostly data folders of multiple VFP apps on a server)
>>
>>I have a table of the apps, their locations etc.. I have included fields for the name of a dbc and dbf that I know cannot be opened exclusively if anyone is in the app.
>>
>>My thought was to programmatically try to open the dbf exclusively and if that fails, delay trying to zip the data folder.
>>
>>The problem is that if I use exclu successfully and then close the table the DBC is still considered open by Winzip and there is an error when you zip it. (dbf zips fine) CLOSE DATABASES ALL is going to close the database my app is using.
>>
>>Is my solution found in using a different data session or is there a trick to tell the os to release any handle on the dbc?
>>
>>Seems I am missing something easy and obvious
>>