>Is it possible that they are running it on two PCs at the same time?

It's a multiuser system, so there might be 10 or 20 users on at the same time, but the exe and data files are on the network, so they are all accessing the same exe and the same user and other data tables. The thing is that some of the user records that seem to be locked belong to users who are still listed in the user table, but in fact are no longer with the company and may not have been on the system for months. Others in the 'currently logged in' list might not have logged into the system for days. 10 minutes later some of them might no longer show in the list. But tomorrow they might again (without having logged in).

>>Does anyone know why RLock() might return .F. when the record it's trying to lock is not already locked?
>>
>>We have a situation with only one client where they check to see who else is on the system and get a list that includes people who haven't been on the system for days (some of whom are no longer with the company at all). When they check again later, some of those people seem to have logged out in spite of the fact that they weren't logged in in the first place.
>>
>>When someone logs into the system, their record in the user table is locked. In order to check who is on, all we do is to scan the user table trying to lock records. If RLOCK() returns .T., we unlock it and move on to the next record. If it returns. .F., we enter the name into an array and move on to the next record. When done, we present the names in the array as being logged on.
>>
>>Clearly, in some cases, RLOCK() is returning .F. even though the record is not locked. Ten minutes later, some of those records are now lockable and RLOCK() will return .T.
>>
>>Anybody?