>>>> Unfortunately, CLOSE ALL is spread throughout the code of
>>>> all the programs so using a low level file open/create to
>>>> make a file that only exists during execution of the program
>>>> won't work. This is the method I've used in the past.
>>>
>>>How about creating a permanent DBF? Every time a user logged
>>>in, a record is inserted into it; logout, removed from it.
>>>A look into the table will know who is/are using a program,
>>>what program, when... Then you can control access.
>>
>>This approach only works if the app NEVER dies or is terminated abnormally. The client's server is EXTREMELY unstable. Users are kicked out several times a week which would leave the records saying that users are still logged. Therefore this would not work in this situation.
>
>If you use a local file, the server isn't involved at all. The problem appears to be a single station running >1 instance, not >1 instance running under a given userid on the network, so a local file would appear to clear that up neatly. No muss, no fuss, no lock release delay issues, etc.



A local file won't work in this situation because if the server dies, they have to reboot their PC's. The apps runs/reside locally but access data files on the network.

The client's server dies several times a week so if the users are kicked out of the app, how does the app know that the system was terminated abnormally and let the users back in when the file already exists? The problem is that I want this to be transparent to the users. If I give them a prompt saying " The App may already be running, are you sure you want to start it again?", the users will blow through the prompt without reading it.

Because the orginal programmer placed CLOSE ALL through out her code, I cannot easily use my standard method of opening/creating a file and leaving it open while the app is running. The original programmer estimated 35 hours to remove all of the CLOSE ALL's within all of the programs. We were hoping for an answer that could be implimented quicker.