James Bott wrote:I was referring to a hang, not a crash. When the computer hangs the file is still locked. It will only be unlocked when the computer is rebooted or turned off. I'm not sure there is anyway to handle a hang.
Application is hang... All in application is hang... so it's very normally handles files too hang... where is a problem ?
And as long as that computer is frozen, any semaphone lock files would remain.The problem is that as long as the computer is frozen, no one else on the network can access the locked file(s).
I'm not saying this is a big issue, but I have had clients that just left it frozen until I came in to fix it. This left everyone else without access to the file. It only happens rarely, but you mentioned your system handled it, so I was curious if you had a trick. The only trick is to reboot or turn it off. At least with your system other users can still tell whose computer has the file locked so they can investigate.
Hello,
And how do You Manage record locks?.
Thank You
Eduardo,
Did you mean file locks or record locks?
Either way, I use database objects. I wrote a subclass to TDatabase which adds many enhancements.
I added some enhancements for record locking including automatic retries if a record is already locked. Personally, I aways use optimistic locking so a record is only locked for a second, so locked records are not really an issue.
I rarely use file locking and I have not really needed to know who has a file locked. I am interested in this topic since it would be easy to add this feature to my database class. For anyone currently using a database class, this would then only require a recompile to add the new feature to an existing program. This is one of the great advantages of using classes.
If you are interested in more info about my TData class go here:
http://gointellitech.com/program.htm
James
James Bott wrote:The problem is that as long as the computer is frozen, no one else on the network can access the locked file(s).
I'm not
FLOCK() is a database function used in network environments to lock an
open and shared database file, preventing other users from updating the
file until the lock is released. Records in the locked file are
accessible for read-only operations.
File locks are issued all the time behind the scenes. Every skip on a shared dbf with an index locks the index file until after skip is complete. This is to ensure that the index tree has not changed until after the next record is resolved. Having the locks cached is not the best idea when each users machine is managing the indexes. If you are using client/server then there is no problem.
I am getting the impression that I offended you
