Hi Denise,
There really isn't a problem if your user login and logout both clear any process flags. Then the moment the user logs back in after a crash the flag is clear. I've not had *any* problems in 4 years with 50-70 concurrent users. Not even a single phone call. And Because they know the name of the user they can easily resolve any issues amongst themselves.
Regards Dave


>Thanks, David. That's exactly what I was thinking about doing but the boss doesn't want to becuase if the system were to crash you'd have all of these "locks" still in there and no one could get to it. I figured if the system crashed or something, the first thing that's done would be the supervisor go in and clear all the locks. But that was vetoed so it's no longer an option.
>
>But thanks for letting me know that my thought processes are on track :)
>
>Denise
>
>>PMJI,
>>But this might be what I call process locking... you only wan't to allow one user at a time to carry out a certain task. This can be done quite simply with an extra field in the user table called "process". A form, or any process which can only be processed by one user at a time can be given a unique name/identifier programmatically and stored in that users "process" field. Before this is allowed you check the user file to make sure that no other user is undertaking that same process. The advantage is that you can advise the user "You can't do this just now because John Brown is doing it" - something that's much more difficult with record locks. Just clear the field when finished.
>>If you don't have a user table create a ddummy one and assign psuedo userids at login to your system.
>>
>>HT Helps and makes sense :-)