Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Anybody experiencing Record Locking Problems in NetWare
Message
From
07/10/1997 13:49:37
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00052955
Message ID:
00053565
Views:
37
>>>>>>FLOCK() AND RLOCK() return .T. and not actually lock. With free tables everything works as expected.
>>>>>>
>>>>>>>>I've got a verified situation where RLOCK() and FLOCK() don't work when issued against a VFP5 database table under NetWare 3.x. Everything works fine is the app is moved to any not NetWare disk (NT, Win95). I've tried flagging the files as shareable and that doesn't work.
>>>>>>>>I've tested the situation in 2 different 3.x networks.
>>>>>>>>Has anybody experienced this situation?
>>>>>>>Does it flock() and rlock() return .t. and not actually lock, or does it return .f. when it should return .t.?
>>>>>
>>>>>I have not narrowed my problem to this specific cause, but I am having update conflicts with certain tables even though I am using RLOCK(). We are using Netware 3.12, and the tables are on the server. Please let me know if you find out more about this problem, it could clear a lot of things up for me.
>>>>
>>>>
>>>>Eric,
>>>> I am sending you the procedures we have been using for a while with fox dbfs and novel 3.x here at Gilbarco.
>>>>we have switched to novell 4 now but you can move these to 5.0 and give them a try.
>>>>
>>>> Hope this helps
>>>> Jeff Butler
>>>
>>>Thanks Jeff...
>>>did you send them e-mail? I haven't gotten anything yet...
>>>
>>>Nice hat...
>>
>>Yes I did and you should have them by now. Send me an email to jeff_butler@gilbarco.com
>>with your correct address. I will try again.
>>
>>Jeff
>>
>>The hat just covers the bald.
>
>Is there any particular reason that FLOCK() and RLOCK() are being used instead of table and record buffering. I am developing VFP5 apps on a Novell 3.12 network and have never had any problems.

The procedure in question is the stored procedure that fetches primary key values for tables with enforced unique indexes. This particular procedure cannot afford an 'update conflict' type error, which would be possible with without record locking. I _do_ use table buffering in my apps, but in this particular instance, it doesn't serve the needs of the application.
Erik Moore
Clientelligence
Previous
Reply
Map
View

Click here to load this message in the networking platform