>>>>This is along the lines of the infamous "Unknown" datasessions. When users need to go to do packing/indexing, they need exclusive use. The database however seems to be able to be opened exclusively (the check) which leads to the mistaken assumption that the tables will also be able to be opened exclusively. Of course, USE xxx EXCLUSIVE blows up and this is typically due to some private datasession still lingering around. CLOSE TABLES ALL, CLOSE DATABASE sometimes don't seem to work properly. Several forms have comboboxes that have SQL cursors created to populate them. I reread the thread posted by Michelle Cox regarding the "Cannot access the selected table" error message which is also happening here. So, what's needed is a sure fire manner to close out everything from a private datasession.
>>>>
>>>>Steve
>>>
>>>You may arrange your app interface the way that data maintenance form (VALIDATE/PACK/REINDEX) can be open only if all other forms closed. This way you assure no interference with other application components.
>>
>>Hi Ed,
>>
>>That is now the case. The process checks for exclusive use of the DBC. But I'm finding that you can get exclusive use of the DBC with "unknown" datasessions hanging around. If other forms/users were on the system, then the DBC is open for them and the user trying for exclusive use of the DBC wouldn't be able to get it.
>>
>>Steve
>
>One should distinct between other forms and other users access. First thing, as I said, might be handled by application flow rules. Second thing is just a matter of checking:
>

>IF Thisform.ResetDatabase(1)=.F.  && try to reopen database exclusively
> IF THISFORM.ResetDatabase(2)=.F. && try to reopen database in shared mode
>  =messagebox("Critical Error!")
>  oApp.closeapplication
>  RETURN
> ENDIF
>ENDIF
>*** run process here
>IF THISFORM.ResetDatabase(2)=.F.  && try to reopen database in shared mode
> =messagebox("Critical Error!")
> oApp.closeapplication
> RETURN
>ENDIF
>

Thanks,
Steve