Steve,

Is this 'old fashioned' type of access or is BUFFERING in use?

What kind of network is this - Win95, Novell, etc?

Actually, I would guess, though, that the RLOCK() is being set on the current record, then the SEEK changes the record to one which is not locked. Yes, that would be my best guess on this one.

Good luck,

Jim N

>I've been asked once again for assistance with a multi-user app in 6.0. It seems that RLOCK() is returning .T. even when a record is locked by another user. I searched back one year reading on others issues with RLOCK. They are trying to lock a parent record and several child records. Forms are private datasessions, reprocess is set to 10, multilocks is on......everything seems correct. I tried this (standalone machine) starting up two instances of the app, sure enough, RLOCK() indicated that both "users" got the lock. Of course, things blew up when the 2nd user tried to update.
>
>I looked at the code, it's like this;
>SELECT SomeAlias
>=SEEK(nKey, "SomeAlias", "TagName")
>IF RLOCK()
> lLockFlag = .T.
>ELSE
> lLockFlag = .F.
>ENDIF
>
>With wait windows, even the second "user" had RLOCK() returning .T.
>I can't help these folks as far as a network goes, but it seems to me that RLOCK() should be locking these records even with two instances of the same app running on one PC.
>
>Any known reasons why RLOCK() would return .T. for both instances but then blow up (record was clearly locked by 1st) when the 2nd user attempts to update? The app checks the flag and notifies the user that the record is locked by another, but it's always .T.
>
>Thanks,
>Steve