I have Delphi application with TIBQUery-TDataSetProvider-TClientDataSet that more or less emulates CachedUpdates pattern (that was in previouse BDE components). Currently there is no error handling code, so, there is no error messages at all. I just want to enable the following scenariou: when query experiences any error coming from database, then all the chaing should stop the work, remain at the current values, rollback already posted changes and show the message. I guess - all this can be done by implementing TDataSetProvider.OnUpdateError. I have 2 code proposals. The first:
procedure TBillDM.BillProvUpdateError(Sender: TObject;
DataSet: TCustomClientDataSet; E: EUpdateError; UpdateKind: TUpdateKind;
var Response: TResolverResponse);
begin
inherited;
raise E;
end;
The other variant:
procedure TBillDM.BillProvUpdateError(Sender: TObject;
DataSet: TCustomClientDataSet; E: EUpdateError; UpdateKind: TUpdateKind;
var Response: TResolverResponse);
begin
inherited;
Response:=rrAbort;
BillQry.Transaction.RollbackRetaining;
ShowMessage(E.Message);
end;
Are those code patterns quite sane? What are guidelines for OnUpdateError
if just want to stop execution and report error? I want zero intelligence in application - I can only provide more meaningfull error message but all the corrections should be done by the user.
should you want to make your app multi-tiered you wouldn't want to ShowMessage within provider event handlers. just use cds.ApplyUpdates with 0 as max error count and utilize OnReconcileError event handler. here's excerpt from "Applying updates" help topic: "ApplyUpdates takes a single parameter, MaxErrors, which indicates the maximum number of errors that the provider should tolerate before aborting the update process. If MaxErrors is 0, then as soon as an update error occurs, the entire update process is terminated. No changes are written to the database, and the client dataset's change log remains intact". isn't it what you're after?