Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Multi User Record Locking / Unlocking

Status
Not open for further replies.

FoxAl

MIS
Nov 27, 2000
40
0
0
GB
Have a problem with Multi User Site whereby if 2 users try to access the same record one gets in but the other receives the error message:-

'Cannot Lock the Current Record in MyFile, Try Again' with options for 'Yes' & 'No'.

This is normal behaviour but once 1 user exits the record and the other hits the 'Yes' button to Retry, the message keeps continuing to show even although no-one else is using either that record or that file.

The problem only happens infrequently but when it does the locking can occur for anything up to 2 minutes - on occassions everyone has to exit and re-enter the system to free resources.

The system is on a Network, all PC's are W98, Set Reprocess = -1, All Memory is optimised.

Any ideas and suggestions are most welcome....

Regards
 
Is the file server also Win98 or WinNT/2000? If it is a true server most have default configurations that can keep a file locked (and/or opened exclusive) for minutes as you've experienced - it's an optimization thing. <s>

Rick
 
Rick,

It is not a true server application, it is used for Word, Excel and another Foxpro Application.

The server is NT4.0.

On the optimisation thing - why would you ever want a file/record locking mechanism that takes minutes to unlock? What do you have to do to make the unlocking instantaneous after issuing a UNLOCK Foxpro Statement.

The File/Record Locking used in the 2nd application is identical to that of the first, yet the first does not experience this abnormal behaviour - any thoughts?

Thanks
 
Ah, you think like a programmer and not a database administrator! :) NT, 2000 and even Novell servers all believe that users / applications never really know what they want, so to speed up access to data, they do everything NOT to have to actually read from disk - rather just serve the data up from the caches. Because of this they don't close files when you close them (&quot;someone is just going to open it again anyway!&quot;) - just let them timeout depending on the configuration. Where this gets real bad is when someone opens a file exclusive (the ultimate file lock!) - it may take minutes before it's actually closed and someone else can reopen it shared or otherwise. Of course if a station locks a record and never unlocks it due to system hang / reboot / power off, it'll also require a timeout before the server will release the lock(s).

Rick
 
Rick,

Thanks, you are right re the unlocking and disk caching. Have now been able to replicate error re ownership of data by 1 user. It seems to work differently though on different Operating Systems.

I have issued unlock command in various code snippets of the form unload events (Deactivate, Read Valid etc) but if you issue a sys(2011) check immediately afterwards it still recognises the record as locked.

Will need to try and write routine to determine how the last read was terminated and add logical field to tables to control the status of current record being locked or otherwise.

Wow! - what a headache.

Regards
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top