0

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.

TomR
  • 2,696
  • 6
  • 34
  • 87
  • 1
    Have you tried handling the `TIBUpdateErrorEvent` and specifying an UpdateAction of `uaAbort` or `uaFail`? – MartynA Dec 12 '18 at 20:04
  • 1
    Just throw an exception. It's a common pattern and the RTL even has the abort method which throws a 'silent' exception. It will break the flow. Easy way out, and also usable in events that don't have another way of bailing out. – GolezTrol Dec 12 '18 at 22:30
  • 1
    Don't throw an exception. It's considered bad practice to use exceptions for control flow. Don't throw exceptions if you don't have to, and catch and convert other exceptions as quickly as possible to normal application flow. In this case, set the resolver response to indicate you don't want to continue. – GolezTrol Dec 12 '18 at 22:34
  • 1
    Listen to Golez, not Golez! – Sertac Akyuz Dec 13 '18 at 00:36

1 Answers1

2

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?

Vladimir Ulchenko
  • 463
  • 2
  • 8