Error Handling Is not Handling 
Author Message
 Error Handling Is not Handling

When an error is triggered by the "gDB.Execute SQL" line below, if
there is an error (ie. record lock), it is handled below where I
attempt to try again.  On the second attempt, it kicks back out to the
calling procedure.  Why would it do this when the "on Error" statement
should take control????

On Error Resume Next    'GoTo Err_mExecSQL
Dim Retries As Integer

ExecSQL_Retry:
    On Error Resume Next
    Err.Clear
    DBEngine.Workspaces(0).BeginTrans
    gDB.Execute SQL, dbFailOnError      'Error Triggered****
    If Err Then
        GoTo Err_mExecSQL
    End If
    DBEngine.Workspaces(0).CommitTrans
    mExecSQL = gDB.RecordsAffected
    DBEngine.Idle dbFreeLocks

Exit Function

Err_mExecSQL:
    DBEngine.Workspaces(0).Rollback
    DBEngine.Idle dbFreeLocks
    Retries = Retries + 1
    Msg = "Record currently locked.  Retry?"   ' Define message.
    style = vbYesNo + vbCritical + vbDefaultButton2 ' Define buttons.
    Title = "Stock96 Process"  ' Define title.

    Select Case Err.Number
        '3158, 3186-Couldn't save, record locked
        '3167-Couldn't update, record locked
        '3260-Couldn't update, record locked
        Case 3158, 3167, 3186, 3260
            If Retries > 3 Then
                Call mErrorHandler(Err.Number, "mExecSQL",
Err.Description)
                If MsgBox(Msg, style, Title, Help, Ctxt) = vbYes Then
' User chose Yes.
                    GoTo ExecSQL_Retry
                End If
            Else
                DoEvents
                GoTo ExecSQL_Retry
            End If

        Case 3189 'Table exclusively locked
                Call mErrorHandler(Err.Number, "mExecSQL",
Err.Description)
                If MsgBox(Msg, style, Title, Help, Ctxt) = vbYes Then
' User chose Yes.
                    GoTo ExecSQL_Retry
                End If
        Case 3022   'Duplicate Index
            Call mErrorHandler(Err.Number, "mExecSQL",
Err.Description)
            DoEvents
            'GoTo ExecSQL_Retry
        Case Else
            'call Error Handler
            Call mErrorHandler(Err.Number, "mExecSQL",
Err.Description)
    End Select
    'SQL Failed. Return a negative error number
    mExecSQL = Err.Number * -1



Sat, 03 Apr 1999 03:00:00 GMT  
 Error Handling Is not Handling


Quote:
> When an error is triggered by the "gDB.Execute SQL" line below, if
> there is an error (ie. record lock), it is handled below where I
> attempt to try again.  On the second attempt, it kicks back out to the
> calling procedure.  Why would it do this when the "on Error" statement
> should take control????

As far as VB is concerned, you haven't reset the Err object, meaning you
are still handling the error. If an error appears in the Error Handling
code, it should bomb out, IMO.

To avoid this, try clearing the Err object (store the error code in a
variable), or rewrite the procedure using On Error Goto <label> and Resume
[<label>].

--
VB Info: http://home.sn.no/~balchen/vb/visual.htm
FAQ: http://home.sn.no/~balchen/vb/faq.htm
Knowledge Base: http://home.sn.no/~balchen/vb/kb.htm



Sat, 03 Apr 1999 03:00:00 GMT  
 Error Handling Is not Handling


Quote:


>> When an error is triggered by the "gDB.Execute SQL" line below, if
>> there is an error (ie. record lock), it is handled below where I
>> attempt to try again.  On the second attempt, it kicks back out to
the
>> calling procedure.  Why would it do this when the "on Error"
statement
>> should take control????

>As far as VB is concerned, you haven't reset the Err object, meaning
you
>are still handling the error. If an error appears in the Error
Handling
>code, it should bomb out, IMO.

>To avoid this, try clearing the Err object (store the error code in a
>variable), or rewrite the procedure using On Error Goto <label> and
Resume
>[<label>].

>--
>VB Info: http://home.sn.no/~balchen/vb/visual.htm
>FAQ: http://home.sn.no/~balchen/vb/faq.htm
>Knowledge Base: http://home.sn.no/~balchen/vb/kb.htm

I have a similar issue in VB$:

I have used the Error command in VB3 to throw my own exceptions.  This
technique works well because I can reduce the amount of error handling
code.  I recently port a large project over to VB4 and converted to use
the Err.Raise function instead.  All works well.

Now, I start writing object code and this falls appart.  When an
object's member function raises an error the VB error handler catches
it not my own that I setup in the calling function.  Of course I'm
curious and discovered that whenever this occurs there is the following
in the call tree:

<non basic code>

These non basic code blocks seem to occur when I call object's member
functions.  This is bad because my whole error handling scheme breaks
down if the errors never make it back to the handlers.  

Is there a workaround for this?  Is there a manual page that I'm
missing?

chuckb



Sun, 04 Apr 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Error Handling (Handle by number)

2. Errors not handled

3. Error handling does not work

4. Handle is not initialized Error

5. Raised error not being handled VB6

6. Error Handling - Not Working - Urgent

7. Error Handling: Disk Not Accessable

8. Error: Could not create DIB handle

9. Page Not Found error handling?

10. Handling error due to table not found in Access database

11. Am I asking to much of transaction handling?

12. Application handle from mutex handle?

 

 
Powered by phpBB® Forum Software