Question: Why would a table need to be opened exclusively? If a table needs to be opened exclusively (for a pack, reindex, modi struct, whatever), it should not be at a point where there is any user input. It should be in code that is executed and then the table is closed without any user interaction. This way you don't get into the problem of a user locking a table and taking a phone call while others are trying to get access to the data. Also, as a reminder, your error trapping routine should handle this error with some type of retry option.

All my personal opinion..

Joe

>You are right - 'keys' is indeed being opened exclusively in another data session. The code that opens 'keys' and gets new keyvalues is in a stored procedure called 'newid' which is called as the Default Value trigger from every keyfield. This code came from TASTRADE. The form that edits the table that generates the error has a private datasession due to an old bug workaround which I haven't fixed yet. It is opened exclusively because it is a legacy app originally designed for standalone use.
>
>I still have some problems:
>
>1. If the keys table gets opened in the other datasession, why does USED('keys') return false? My debugger indicates that no alias for 'keys' is being used at any point, and I have no code that gives it an alias. Is this a known bug? Was it fixed in version 5 or 6?
>
>2. This stored procedure is part of my framework, and needs to account for the general possibility that it will be called from tables opened in forms that have private datasessions and SET EXCLUSIVE ON. I assume that the code in TASTRADE didn't close 'keys' because it assumes otherwise, and because closing and opening this small table repeatedly would slow things down. Do I have to close 'keys' in the stored procedure newid() anyway, or is there a better workaround?
>
>>Hi Bret,
>>
>>It sounds like you may have the table opened exclusively in another data session. To check this, after you get the error suspend and open the "Data Session" Window from the "Windows" menu. Check the "Current Session" dropdown to see if there is another data session open. If so, select it and see if the table in question is open there. If this is the case, you'll need to track down where this is happening, and modify your application to either close the table, or open it shared (set exclusive off).
>>
>>
>>>I have a table of valid keyvalues called "keys" in my database "skaset". When adding records, I open the keys table with this:
>>>
>>>

>>>IF !USED("keys")
>>>    USE skaset!keys IN 0
>>>ENDIF
>>>

>>>
>>>but if it has already used and later is closed, it sometimes (with a certain table) gives me "Error 3 - file is in use". How can I be getting that error? The debugger says that USED("keys") = .F. when I get the error. Is there a problem with opening, closing, and opening a table again?