One of the most requested features for Data Abstract in the past has been to provide a UI to handle update failures automatically and intuitively. Presenting update failures in a decent way that is not a simple task, as the end user often isn’t aware (and shouldn’t need to be aware) of the implementation details of the database.

For Vinci, we’re adding a set of reusable dialogs to Data Abstract (in both editions), as well as an infrastructure that makes it easy for developers to provide their own customized versions, or to hook up a custom UI.

Whenever one or more changes failed to be applied on the server, the client will automatically present a dialog as shown below (optionally, of course – the new FailureBehavior property on the RDA controls whether to show the dialog, raise an exception, or do both – the latter being the default):

Note how a list on the left shows all the failed changes, by default displaying table name and primary key, although that information is customizable thru event handlers. We’re also showing an icon to indicate whether the change in question was an Insert, Update or Delete.

Selecting any of the changes (the first is selected by default), the right-hand side will show more details about the problem, including a plain-text description of the failed action (again customizable), as well as the original error message received from the server – which is usually database specific.

Below that, three simple and self-explanatory options are provided for the user:

  • skip/ignore the error for now (the change will be applied again later); this option assumes the user will somehow try to correct the problem later on
  • cancel/discard the change altogether
  • show the record in question in more detail

The third option is the most powerful one: by default it will bring up one of three ready-made dialogs showing all the fields of the record, highlighting any changes (for Updates), and giving the user the option to correct any mistakes right there:

As mentioned before, one of the critical aspects of providing a good reconciliation experience for the end user is to hide the user from the database implementation details he shouldn’t know about. Depending on the type of UI your application uses, simply showing a list of database fields will be of little help to the user, who is familiar with your usual UI but not aware of the database field names, lookup values, and so on.

For this reason, the reconcile architecture again exposes hooks that allow the developer to provide a custom UI to present the data – for example if editing of a Customer record failed, your application could show it’s standard edit mask for Customers, allowing the user to fix the problem right there, instead of in the generic dialog shown above.