Hello,
If a record is locked by someone else, is there a possibility that this record can unlocked by another user?
Thank you.
Regards,
Michel D.
Genk (Belgium)
I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773
My thoughts:
Each lock is associated with a workarea. Each workarea is managed by the terminal or session of each user.
Perhaps ADS could because it is a client/server system.
But I think Harbor can't do that.
I have needed it on some occasion and I have not been able to do it
regards
Michel,
I would think that would become a nightmare. What is the reason that you want to do this?
James
James,
I agree that this could lead to drama's.
But I have a reason.
I have customers who use my application in a remote desktop environment.
Sometimes they just close the session without login out.
So the session stays active, the files opened and the records locked.
They start a new RDP-session, launch my application and then discover that some records still are locked.
Of course, then I got a phonecall to help them out of the problem.
Since I don't have access to the server, I need to ask to my customer to reboot the server.
That means that all other users have to stop working, etc.
That's why I'm looking for another way to unlock the locked records.
Of course, I want only the administrator to do such actions.
Regards,
Michel D.
Genk (Belgium)
I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773
driessen wrote:Hello,Not possible.
If a record is locked by someone else, is there a possibility that this record can unlocked by another user?
Thank you.
nageswaragunupudi wrote:Well behaved programs never lock a record and wait for a user action.Perfectly said. I completely agree.
Lock only when all data is ready, then lock and write all data and unlock immediately.
The entire action should not take more than a fraction of a second.
nEvent := 0
DO WHILE !lExit
nEvent := APPEVENT( @mp1, @mp2, @oXbp, nTime ) // 4th Parameter Timeout
DO CASE
CASE nEvent == xbe_None
EXITDriessen,
I think there is another way to handle your problem, but it is a bit complicated.
Instead of the program locking a record when a user opens it and only unlocking it when the record is saved, the record is only locked for a split second when the record saved. Thus, nobody can walk away leaving a record locked.
One solution is that when the program reads a record into a dialog for editing, it also copies the original data to a second buffer. Then when the user2 selects to save the data, first the program reads the record again and compares it to the original data in the second buffer. If a change has been made to the record, then the program notifies user2 that the data has been changed, and does user2 want to abandon their current changes or re-read the record and make their changes to the newly revised record.
If user2 wants to remake the changes, the program re-reads the record and goes back into edit mode. Next, user2 modifies the record again. When they go to save the changed data, the program again re-reads the record from the disk and then checks all the fields to see if any are different than the original in-memory copy. If not, then the modified data is written to the disk.
I have not tested this.
Like I said, it's complicated.
METHOD RLock(f_nRecno, f_nLockSeconds) Class TAds
Local lLockRecno := .F., iForTentativa := 0, lc_nLockLoops := 0
Default f_nRecno := (::cAlias)->(Recno()), f_nLockSeconds := 5
lc_nLockLoops := (f_nLockSeconds / 0.2)
If (::cAlias)->(Recno()) != f_nRecno
(::cAlias)->(DbGoTo(f_nRecno))
::OnSkip()
EndIf
For iForTentativa := 1 To lc_nLockLoops
(::cAlias)->(AdsRefreshRecord())
If (::cAlias)->(DbRLock())
::cAuditProcess += If(!Empty(::cAuditProcess),Replicate("-",80)+CRLF,"")
::cAuditProcess += "ACE Api > AdsLockRecord("+cValToStr(::Recno())+") Table "+;
::cTableName+CRLF
::lAppendRecord := .F.
lLockRecno := .T.
Exit
Else
SysWait(.2)
EndIf
Next
RETURN lLockRecno