>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.
JESS S. BANAGA
Project Leader - SDD division
...shifting from VFP to C#.Net
CHARISMA simply means: "Be more concerned about making others feel good about themselves than you are in making them feel good about you."