"File is in use by another user" or "Record is in use by another user" - with Er

[KALP1]

As soon as I put my Error Handler in action , above message comes every now and then when multiple user are working on the same file. When I place no Error Handler with VFP's Default error messages, these errors disappears. I have SET ReProcess to 4. Problem is that as soon as I place Error Handler and error occurs VFP Ignores SET REPROCESS settings and Error Handler displays message . So is there any solution for to use error handler along with Set Reprocess settings

 

[Mike Lewis]

Can we assume that when you see this message, you are in fact editing or amending with a lock in force? If so, the behaviour you are seeing is normal and expected.

What you need to do is to trap the specific error within your error-handler. If the error is 109, then you should display a message advising the user that another person is editing the record and they should try again later. You then issue a RETRY. The user can then either try to the edit again, or they can close the form and do something else within the application.

I'm assuming you are using a pessistic locking mode. If you are using optimistic locking, the strategy is quite different.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dbMark]

Would it resolve your problem if you place the code in question within a TRY/CATCH [TO oErrorObj]/FINALLY/ENDTRY ?

If you create the error object with CATCH TO then your code can determine what to do with the error. And if it is in a proper loop then you could retry that piece of code based on the contents of that error object.

http://www.sweetpotatosoftware.com/...essional-error-handling-for-vfp-applications/

 

[KALP1]

Mike,I have written below snippet in my error handler routine
Do Case
Case lnErrorNo = 109
nAnswer =Messagebox("Record in use by another user, please try again",5+48+512,"Record in use")
Do Case
Case nAnswer = 3 &&Abort
CANCEL
lnProgFlow = 7
Case nAnswer = 4 &&Retry
RETRY
lnProgFlow = 1
Otherwise && Ignore
lnProgFlow = 6
*Return
Endcase
Case lnErrorNo = 108
nAnswer = Messagebox("File in use by another user , please try again",5+48+512,"File in use")
Do Case
Case nAnswer = 3 && Abort
CANCEL
lnProgFlow = 7
Case nAnswer = 4 && Retry
RETRY
lnProgFlow = 1
Otherwise && Ignore
lnProgFlow = 6
*RETURN
Endcase
Otherwise
.................
ENDCASE
***
When Error occurs and user presses RETRY button, messagebox comes again and again for retry and nothing happens . So am I wrong somewhere in above code.

 

[Olaf Doschke]

This error is no real error, its just the info about a lock. It happens, even if you don't manually lock any rows, every write operation causes automatic locks.

Doing as you do, with RETRY, can get the use of a table woirking, if the lock is just a temporary automatic lock, but you can't overcome a real and long lasting lock, eg by a table in use EXCLUSIVE.

So in the end the user has to give up at some point. There is no forcing of breaking locks.

Bye, Olaf.

 

[Mike Lewis]

Well, for a start, your logic is dubious. You should never give an option of Abort, Retry or Ignore after an error message. It is not up to the user to decide what to do after an error. "Ignore" is certainly wrong. You should never have the user ignore an error. And what does "Abort" mean in this scenario? Abort the entire execution of the program - just because the record is locked?

Also, I would think CANCEL is incorrect in this context. That will simply cancel the errror-handler, which is not what you want. What you do want is RETRY.

I would suggest something like this:

DO CASE
  CASE INLIST( lnErrorNo, 108, 109)
    * Pessimistic file or record lock. After the RETRY, the user will be
    * able to continue editing after the lock has been released.

    lcMess = "Another user is editing this data." + CHR(13) + ;
      "Please wait a moment and try again." 

    llRetry = .T.

  CASE .... [i]<deal with other errors here>[/i]

ENDCASE

MESSAGEBOX(lcMess)

IF llRetry
  RETRY
ELSE
  [i]< gracefully close the application >[/i]
ENDIF

I haven't tried to test this code, but I think it is close to what you need.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

While in general continuing after ignoring an error leads anywhere but into a good and stable state, the options to exit error handling are stated clearly:

https://msdn.microsoft.com/en-us/library/fheb37ye(v=vs.80).aspx

If the error-handling procedure includes the RETRY command, the program executes the line that caused the error instead of continuing on the immediate following line.

Continuing on the immediate following line is what happens, if you RETURN from the error-handling procedure. That's what you also can do with the Ignore button of the native error handling, but as Mike says not really recommendable.

In fact TRY..CATCH gives you best control to act on the error locally, just with several settings of REPROCESS, see

https://msdn.microsoft.com/en-us/library/ms714159(v=vs.85).aspx

Several paragrpahs here tell you what happens with an ON ERROR handling in effect. I'm quite sure TRY..CATCH will take precendece over ON ERROR as usual, though, so you can handle the problem locally and decide how to continue having no write access or even not get the table open overall.

Bye, Olaf.

 

[Mike Lewis]

Regarding TRY/CATCH, how would that work in an interactive editing session? Suppose you launch a form with editable fields, and the form has pessimistic buffering enabled. Wouldn't the error be triggered at the point where the user hits a key to edit one of the fields? That's certainly how it appears.

If that's right, where would you place the TRY/CATCH? Not around the DO FORM command, surely?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

In the end I would opt for no locking, optimistic, buffered. Then you can always edit. The TRY CATCH will then be around saving changes with TABLEUPDATE.

Bye, Olaf.