Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
When is an rlock not an rlock
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
01257756
Message ID:
01257779
Vues:
11
>Alan,
>
>What I think Sergey was saying might be the reason. Imagine two users running this very same code simultaneously, then the first rlock will fail, not because the user is locking it, but because another using is locking it for checking. Granted, it is a very small window when this might occur, but is not impossible. You might try to change you SET REPROCESS value to see if this fixes the problem, or a more drastically way would be to have a semaphore table for this process.

I guess it's possible, but it would also mean that just about every time one person is running the code, so must someone else be. This is a consistent and persistent problem with this client, but not with any of our other clients - at least one of whom has more users on at one time. I thought about changing the reprocess value, but haven't had a chance to check it out yet.

>
>>Thanks Hugo.
>>
>>I don't think that's the issue. It's a fairly simple procedure:
>>
>>
>>select sy_user
>>* set my record number
>>nRecNo = recno()
>>go top
>>
>>lcUsersOn = ""
>>do while !eof()
>>  * add name if record is not lockable or if record is me
>>  if !rlock() or recno() = nRecNo
>>     lcUsersOn = lcUsersOn + Alltrim(sy_user.us_name) + Chr(13) + Chr(10)
>>  Else
>>    if recno() <> nRecNo   && It's not me, so ok to unlock - leave mine locked
>>      unlock record recno()
>>    Endif
>>  endif
>>  skip
>>enddo
>>
>>Goto nRecNo   && back to my own record where I belong
>>
>>MessageBox(lcUsersOn,64,"Current Users")
>>
>>
>>And as I said, this only happens with one particular client. I've never seen it with any of our other clients.
>>
>>
>>>Alan,
>>>
>>>I do not have any idea but the obvious, sorry about that, but did you check your "checking" mechanism? Maybe there is some condition where you fail to unlock the record you RLocked to test if the user is online.
>>>
>>>
>>>>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?
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform