Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DataErr 2169 Customization

Status
Not open for further replies.

sko

Technical User
Dec 9, 2000
283
US
Using the form's error event, I've replaced the default message for the error 2169 "You can't save this record at this time..." with one of my own but I would like to keep the yes/no button functionality of the original message. I want the user to remain on the record until he corrects or discards it. Is this possible?
 
Something like....

On Error GoTo Err
Code
Somewhere:
Code
Err:
If Err.Number = 2169 Then
If MsgBox("Your message.", vbYesNo, "Title") = vbYes Then
Do something.
Else
Do something else.
End If
End If
Resume Somewhere



Randy
 
Thanks for the quick reply, Randy.

My problem is I have to suppress the default message with response = acDataErrorContine in order for my custom box to appear. When I do, Access defaults as if the user chose the “yes, I want to close anyway” option from the standard error message and ignores any procedure I’ve added in response to my message box. I wonder if there is some way to set the Access default to the “no, don’t close” option. Maybe it’s just a training issue for the user. Here is the code I’ve been working with.

Private Sub Form_Error(DataErr As Integer, Response As Integer)

Select Case DataErr
Case 3314
DoCmd.Beep
MsgBox "A required field is blank.", vbCritical
Response = acDataErrContinue
Case 2113
DoCmd.Beep
MsgBox "Wrong Data Type. " & vbCr & _
"Example: You may have entered text in a date field.", vbCritical
Response = acDataErrContinue
Case 2169
If MsgBox("Record is incomplete. Your changes will not be saved." & vbCr & _
"Do you want to review your changes?", vbYesNo, "Record Error") = vbYes Then

'Do something here to cancel closing the record

Response = acDataErrContinue
Else
Response = acDataErrContinue
End If
Case Else
Response = acDataErrDisplay
End Select

End Sub
 
This could possibly be a rather tuff one, because, correct me if I'm wrong, it's about what happens when a close of the form is invoked from the "x" thingie in the upper right corner (thougn it can perhaps also be invoked by a custom close button, but that one has some flaws;-))?

Remember the form error event isn't a validating event, there's probably not much you can do there, except substituting select form error messages with your own... I think the form error event, happens after the before update, and the before update is the event where you can cancel a save operation... I think, catching this in the before update event of the form, is probably more likely to provide a path to a working solution?

Though perhaps not entirely according to requirements, have a look at the approach I outlined here thread702-866344 - involving

- disallowing the "x" - thingie
- using the most reliable save method
- trapping what happens in the before update, to determine how to procede

Could any of this fit into your approach?

Roy-Vidar
 
Thanks for the reply Roy-Vidar,
Yeah, I'm already using the update events for data validation and I thought about forcing the use of an exit button. I'm just thinking about the user that will ignore the prompts, not understand the Access message and close the form or the application. It seems like there should be some way to kill the default action.
 
The before update event of the form, not the before update events of the controls...

I'm not sure I understand what you wish to kill - but the approach I outlined, should "trap the form error before it occurs" - i e use the before update event of the form to allow you to handle invalid entries, disallow save, closing or not of form at your own convenience, without invoking the form error event...

Roy-Vidar
 
Hi Roy-Vidar
I am already using the form's before update event to validate the data before the record is saved. I display a message, set the focus to the offending control and cancel the update. But as you know, if the user closes the form without correcting the record, form error 2169 is triggered. I want to replace the default "..Access may have encountered an error.." with a more user friendly message and yet keep the "yes I want to close" or "no I want to cancel" functionality of the original Access error message box.

The problem is, to see my message box in place of the Access message I have to set response = acDataErrContinue. When I do this, Access closes the form as if the user chose the "I want to close the object" button. The user doesn't have a chance to review the record. I am looking for a way to cancel this behavior.

 
No - in my very humble opinion, the problem isn't the message box from the form error event, the problem is that you allow the form error event to trigger for this (closing form), in stead of trapping this in the before update event of the form.

To reiterate (or again, use a textual description of the referenced code, which is also described in the reference)[ul][li]get rid of the "x" thingie - and force the user to use a custom close button[/li][li]use a form public/private boolean variable you set depending on whether or not closing the form is intended (set in the custom close routine see referenced code)[/li][li]use appropriate means of calling an explicit save when the close button is called[/li][li]handle the validation in the before update event of the form - and based on the result (return/selection from user) - determine how to proceed (close without saving, return to the form, close with saving...)[/li][/ul]Due to the sequence of events, and how Access treats the "x" thingie, I don't believe what you wish to achieve is achievable through the method you wish to achieve it through, which is why I try to push you in a direction of a suggestion that I have working on my setups. The OP in the referenced thread found another solution to their challenge. Another alternative is unbinding the form.

Good Luck!

Roy-Vidar
 
Roy-Vidar,
Thanks for confirming that it is not possible to override the default action within the form error event. As I mentioned in a previous response, I was considering forcing the use of a cutomized exit button as an alternative.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top