View record locking/deadlocks

[virtualranger]

Occassionally we have problems with record locking. Upon attempting to edit a record, the user receives an error saying that record is locked by another user when apparently there is no one in it. I cannot edit the offending record from table view either.

Is there a way to see which records in a table are currently locked, and by which user or process?

Our app is Fox Pro for Dos btw.



Cheers,
Jamie

 

[rob444]

Perhaps you should write code that prevents this kind of locks.

Do you have any code to show where locks are implemented?

Rob

 

[DSummZZZ]

In answer to the question, no.
You can see who has the file open using various methods, but you can only attempt to lock a record yourself to see if it is in use.
Dave S.

 

[Dgoldswo]

Also make sure your code UNLOCKS the record after the
flock().

 

[advancepack]

I can try for your following typed

"Is there a way to see which records in a table are currently locked, and by which user or process?"

1) You will have to write a code with GO RECORD and ?rlock() if it returns .f. the record is locked by another user. 2nd opton you can find ahead.

2) Manytimes I have scratched my head to find out about locking (Who has placed the lock) One solution is there.

A) When you open your application make a code for <User ID> and you restrict to enter User ID, When !empty(User_ID) continue.

B) Whatever you data structure may be, you will have to add one more field U_ID.

Now, whenever you placed Rlock() you can replace U_id with User_ID (the Name of User)

This replaced field can browse by another user and find out who has placed the Lock.

But before UNLOCK you have to blank U_id field and immediately UNLOCK.

Important thing is you will have to write a additional code to find !empty(U_id) AND rlock(). If you find rlock() is true and !empty(U_id) then you will have to blank forcefully. WHY THIS, you placed rlock() and if .T. you replace U_id with User_ID and POWER SHUT OFF the record will unlock automatically but U_id would not BLANK.

3) Now third option is &quot;Which function/procedure placed the lock ?&quot;

hammm

But why you want this ?

 

[virtualranger]

Thanks, good idea for finding the user using User_id in that last post.

Regarding the actual source of the locking problem - we cant find it (we think we are getting close though!). I was hoping to find out who has actually locked the file (and then find out what tasks they were performing) to make it easier to discover the route of the problem. Cheers,
Jamie

 

[rob444]

It cannot be real difficult to find a piece of code where someone edits a non exclusive table or where someone adds a record to it I think.

When editing a record - or even browsing it - foxpro locks these record(s) and not always unlocks them.

Rob

 

[GrayCat]

Hello all,
Could you please elaborate on "not always unlocks them" from the above post? Is there something I can do do assure that the unlock happens?

We are all of a sudden having a problem with extensive record locking messages in a legacy 2.6a FOXPRO application that has been successfully running with a rare but occassional record lock message. This has been very simply managed under FOXPRO record locking.

I have had record locking on a browse on replace and on show gets. At least that is the source code reported in the error logs at the time of the record locking messages.

I have a new development PC on XP and have had a great deal of trouble with corrupt project files, and other unexplained anomalies.

I have checked with the network admin people there have been no changes in our server environment that would contribute to a record locking problem.

It almost seems like Foxpro is not unlocking records.

I welcome any suggestions.

 

[DSummZZZ]

When editing a record - or even browsing it - foxpro locks these record(s) and not always unlocks them.

The act of BROWSE-ing doesn't lock any records or tables unless you actually modify a field. Fox will lock the record at that point, and will normally unlock it once you move off the current record.
Issuing an UNLOCK ALL will release any locks on any records or tables, but they will still be in use shared. If you are still having locking problems, it could be either the server or the workstation not releasing the locks fast enough.
Check the timeouts on the workstation, in the network client properties. Maybe set caching and buffering off.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[MBSCSI]

From the command window, display status will show which record is locked. I'm not sure what else it will show.

The real thing is you need to change the code to handle record locking and use the unlock command when the editing is complete.

What I do is create a user controlled variable called sy_time. Which is in seconds. If no action taken the read terminates

All reads are done with read timeout(sy_time)

select file
select record
do while not rlock() &&lock record
enddo
read timeout(sy_time) && read for a specified # of seconds
unlock

There are issues of deadly embrace which is what you are experiencing. With my method, if you are careful in constructing your code, all records will unlock after a short wait and allow for editing after which the record will again unlock.