A refused save does not show in the validator's summary
The data source rejects a record (because of a table's validation rule, or because a data service
rejects it through its ODBC driver), and the record stays unsaved, but the WklValidator summary
stays empty (ErrorSummary is empty and ErrorCount is 0). Instead, an error number such as 3155
or 3316 reaches your VBA code.
Environment
WKL Forms Object Library 1.31 and later, with HandleDataErrors = True. Microsoft 365 Access, 32-bit;
other versions aren't supported.
Cause
The validator receives such errors through the form's Error event (Form_Error). Access raises
that event only for a save it performs on its own initiative during a user action: the user moves
to another record, closes the form, or clicks from an edit form into another part of the window. A
save that VBA code starts reports the error to that code as a run-time error, and Access doesn't
raise the Error event:
Me.Dirty = FalseorRunCommand acCmdSaveRecord;- moving the focus in code, for example
area!grdMain.SetFocusfrom a docked edit form: the save Access performs at that moment belongs to the code that moved the focus.
This applies to both kinds of rejection: a table's validation rule (error 3316) and a data service that rejects the record with HTTP 422 through its ODBC driver (error 3155). In both cases, the record stays unsaved and dirty, the error goes to the code, and the validator doesn't receive an Error event, so its summary stays empty.
Resolution
Catch the error in the code that saves the record or moves the focus, and pass its text to the validator:
Private Sub cmdSave_Click() On Error GoTo Rejected Me.Dirty = False Exit Sub Rejected: Me!Validator1.Object.SetError "", Err.Description End SubFor an ODBC error,
Err.Descriptioncontains only Access's general text (“ODBC–call failed.”); the driver's reasons are inDBEngine.Errors.- If
Form_Errornever sees a rejected save, the save was started by code (Me.Dirty = False,DoCmd.RunCommand acCmdSaveRecord): handle the error where the code saves.