>>>ar>>I have an application that's not coded correctly
>>>>>to handle error 1705, which happened when you try
>>>>>to open a DBF that has been exclusively opened by
>>>>>another application.
>>>>>
>>>>>use dbfname shared
>>>>>* the codes assumed 100% successful open
>>>>>replace field1 with value1
>>>>>
>>>>>They should have trapped the error and then check
>>>>>USED("dbfname") before doing anything (like the
>>>>>followings).
>>>>>
>>>>>on error do errhand with errproc()
>>>>>use dbfname shared
>>>>>if !used('dbfname')
>>>>> return .f.
>>>>>endif
>>>>>replace field1 with value1
>>>>>
>>>>>procedure errproc
>>>>>parameter m.error
>>>>> if m.error=1705
>>>>> return
>>>>>
>>>>>Is there a simple way to work round this problem without
>>>>>the need to insert extra codes after _every_ USE sections
>>>>>in the system? There could be a hundred of this sections
>>>>>littering everywhere in the system.
>>>>
>>>>PROCEDURE mainprogram
>>>>ON ERROR DO errhandler WITH ERROR()
>>>>USE dbfname IN 0 shared
>>>>
>>>>
>>>>PROCEDURE errhandler (nerror)
>>>>DO CASE
>>>>CASE nerror = 1705
>>>> WAIT WINDOW 'File is being in used by another user. Retrying access...' NOWAIT
>>>> RETRY
>>>>CASE nerror = etc.
>>>>
>>>>
>>>>ENDCASE
>>>
>>>Careful with this... users don't like an endless loop that they can't escape from.
>>
>>Hmmmm... Then I leave it to the developer's decision if He/She will adopt the same approach. Mine is just sharing the logic behind on how we handle the scenario.
>
>My error handler gives the user a choice to retry or quit. This way, if he knows who has the file open exclusively, he can close it and continue, but if he doesn't he can alwaya cancel the operation.

Yes ofcourse. But what I am only trying to instill here is the logic regardless of how you want the system do when the error is triggered. Lots of options actually depending on the developers perspective.