Stang70Fastback
Registered User.
- Local time
- Yesterday, 21:23
- Joined
- Dec 24, 2012
- Messages
- 132
Okay, so I'm probably doing something dumb, but I'm TEARING MY HAIR OUT over this.
I've got a continuous form, and one of the ways I allow users to clear out records in this form is by clearing out the first combo box. SO, I have this chunk of code, which works just fine for the job (basically this code is, in a nutshell saying, "If the box is blank, then just delete this record entirely.")
However, if the user, rather than clearing the combo box, types a SPACE, then Access completely ignores this code, as if that would present a different error. Instead, it makes it all the way to my root Error Logging code (which stores untrapped errors in a table for future review.) If I look there, the code is logged as... ERROR 3162...?!
Strangely, though, if I change my chunk of code to read "If DataErr <> 3162 Then..." it works properly! So then I added a "MsgBox DataErr" line so that I could see what Error Number it WAS associating with this error, since it seems to be wrongly associating a different error number, and the MsgBox itself just comes up blank.
Is this an Access Bug? What am I missing here?! It logs the error correctly in my table (which uses Err.Number), but there seems to be some intermediate point at which the associated DataErr value is just... null? Everyone uses DataErr, but should I be using Err.Number instead in my error-trapping code? What I find weird is that if this error is triggered by a truly Null field, it behaves properly, but if the error is triggered by a field with a blank space, then it's as if in the Access programming end, that error is triggered from a different line, where Microsoft forgot to actually specify a value for the DataErr property...
I've got a continuous form, and one of the ways I allow users to clear out records in this form is by clearing out the first combo box. SO, I have this chunk of code, which works just fine for the job (basically this code is, in a nutshell saying, "If the box is blank, then just delete this record entirely.")
Code:
If DataErr = 3162 Then
Response = acDataErrContinue
If Me.Dirty Then
Me.Undo
End If
If Not Me.NewRecord Then
CurrentDb.Execute "UPDATE Timesheets SET ModifiedName = '" & fOSUserName() & "', ModifiedTimeStamp = #" & Now() & _
"# WHERE Badge = " & Me!Badge & " AND WeekEnding = #" & Me!WeekEnding & "#;"
DoCmd.SetWarnings False
RunCommand acCmdDeleteRecord
DoCmd.SetWarnings True
Me.Parent.Refresh
End If
End If
End SubHowever, if the user, rather than clearing the combo box, types a SPACE, then Access completely ignores this code, as if that would present a different error. Instead, it makes it all the way to my root Error Logging code (which stores untrapped errors in a table for future review.) If I look there, the code is logged as... ERROR 3162...?!
Strangely, though, if I change my chunk of code to read "If DataErr <> 3162 Then..." it works properly! So then I added a "MsgBox DataErr" line so that I could see what Error Number it WAS associating with this error, since it seems to be wrongly associating a different error number, and the MsgBox itself just comes up blank.
Is this an Access Bug? What am I missing here?! It logs the error correctly in my table (which uses Err.Number), but there seems to be some intermediate point at which the associated DataErr value is just... null? Everyone uses DataErr, but should I be using Err.Number instead in my error-trapping code? What I find weird is that if this error is triggered by a truly Null field, it behaves properly, but if the error is triggered by a field with a blank space, then it's as if in the Access programming end, that error is triggered from a different line, where Microsoft forgot to actually specify a value for the DataErr property...
Last edited:
