Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Header locking
Message
From
08/09/1999 21:17:46
 
 
To
08/09/1999 16:50:19
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Title:
Miscellaneous
Thread ID:
00262231
Message ID:
00262698
Views:
18
Eric & Charlie,
I have SET STATUS OFF so that's not the culprit. Will try SET NOTIFY off as per my other post and your suggestion Eric.
In the end I could try the RLOCK(0) which locks the header. But this is a heavily used critical table. If my web server enigine dies while the header lock is in affect I'm a dead man. And I'd be safer in Indonesia :-). So I'm a little nervous about an explicit lock. But, if all else fails, I think Charlie's suggestion is valid.
Thanks guys.

BTW, please understand the time zone difference here, I'm sleeping while you chaps are solving my problem, LOL. Really appreciate the help though!


>Well, then, it appears that SET STATUS would solve the problem. David?
>
>Charlie- I don't personalyy use RLOCK for anything except when I need transactional results, like in a NewID() routine that gets a unique key for a table.
>
>But how would RLOCK() ensure that the table header could be locked? What David was experincing was the locking of a table header that occurs when a record is inserted, or when a command that has whole or partial scope on the table is being executed (DELETE FOR, REPLACE FOR, etc).
>
>Issuing an RLOCK would ensure that the current record could be locked, but seems to me to be of no help when inserting a new record...
>
>
>
>>Erik,
>>Help says: Visual FoxPro displays the "Waiting for lock ... " system message only if SET STATUS is set to ON.
>>So I assume if you SET STATUS OFF, no system message.
>>
>>But what I was saying is to not use the automatic locking at all, but do it manually. If I RLOCK(0), and it returns .T., I insert, if it returns .F., I wait some random milliseconds, and attempt RLOCK(0) again. There's no problem with Waiting for lock then, is there?
>>
>>>this is indeed a different way about it, but doesn't get around the root of the problem: when VFP tries to lock a record, it usees the SET REPROCESS setting, and if it is anything but 1, will keep attempting to lock the record, depending on the setting. During these successive attempts, VFp gives the user a message "Attempting to lock..." and this qualifies as UI, a no no for an In-Proc server.
>>>
>>>
Previous
Reply
Map
View

Click here to load this message in the networking platform