FLOCK() - Why?

[SnyAc]

I'm tasked with maintaining and updating a 'legacy' app that spans approx 10 yrs of VFP changes and techniques. The use of file locks (FLOCK) is spread throughout based on the premise that 2 network users appending a blank record to a table could end up trying to update the same record. I personally have never believed that to be true but that is the logic presented to me in explanation for why they used FLOCKs. Can anyone support/refute this belief?

If I am correct and the FLOCK is not needed it will simplify my support tasks.

Thanks....

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

 

[Mike Lewis]

Andy,

There are many variables in play here, and no one-size-fits-all answer. A lot depends on whether you are using automatic or explicit locking (I'm assuming you are not using buffering, otherwise the issue would not arise).

In general, when you issue an APPEND BLANK, VFP will try to take an automatic lock on the file header. This is to protect the record count in the header, in the case where two people append at the same time. The actual records would be successfully appended come what may.

If you prefer to rely on explicit locks, then it probably does make sense to do a FLOCK(), for the same reason.

Are you experiencing any specific problem with the existing code? If not, I can't see any reason to remove the FLOCK()s.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[SnyAc]

Mike .... we are experiencing some difficulty with the code and the file lock seems to be the culprit. When I have asked the original author of this code (fortunately he still works for the company) and in discussion on this problem in a programming meeting, he has stated that the file lock was necessary in order to be sure of the append blank record situation I described. I have always believed that what you told me was true and have always experienced that in my 15 yrs of foxpro network programming. I've never used file locks and personally would never use one due to the potential for network lock problems that we're seeing. I believe that the original thought process on the file locks must have been based on Foxpro 2.6 network requirements and the code was never updated to visual standards... (plenty of that in this application).

I'm trying to backtrack thru the code calls to see if the file lock is truly necessary. Since this is an accounting/manufacturing application I am reluctant to just remove the file locks (even though I'm 99.9% sure that the inherent FoxPro automatic record locking is doing exactly what it's supposed to).

Anyway.... thanks for your input... You verified what I have always believed to be true about how the network/multi-user record locks worked.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

 

[DSummZZZ]

Let me add to Mike's comment. If user A issues an APPEND BLANK, their record pointer will be pointed at the currently appended record unless it is explicitly moved. Hence, if user B also issues an APPEND BLANK, they will be pointed at their currently appended record, unless they also explicitly move the record pointer. FLOCK has no bearing on where the record pointer is located for which user.

On that note, if you use variables and INSERT INTO ... instead of trying to maintain locks, you will never have to worry about two users trying to update the same record, or the system keeping the file or record locked any longer than absolutely necessary.



-Dave Summers-

Even more Fox stuff at:

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

 

[SnyAc]

I know that one of the other programmers has already replaced some of the append blank code with insert from code (which is a practice I totally agree with) so I've written a function call that does the append blank without requiring a file lock. The function tests for the 'File in use' error that would be thrown if another user is appending a blank record at the same time and gets the lock on the table header first. I'll have to do a code search on the entire project to find all of the places this file lock function is called... but it will be worth it to get rid of this network headache bug....

Andy Snyder
SnyAc Software Services

http://www.snysoft.com