As the sample procedures in earlier chapters show, you can create a general-purpose update API that can take changes made to any ProDataSet and apply them to the database, even executing validation procedures for the specific ProDataSet if they conform to a standard naming convention. This approach is very much like how the SmartDataObject and SmartBusinessObject in the ADM2 handle their update logic.
The generic update procedure in the samples is commitChanges.p. The sample entity procedure, OrderEntity.p, wraps this in a call of its own to provide an API for other procedures to use, as shown:
PROCEDURE saveChanges:
DEFINE INPUT-OUTPUT PARAMETER DATASET FOR dsOrder.
DEFINE VARIABLE hDataSet AS HANDLE NO-UNDO.
hDataSet = DATASET dsOrder:HANDLE.
DYNAMIC-FUNCTION("attachDataSet" IN hSourceProc, hDataSet).
RUN commitChanges.p (INPUT-OUTPUT DATASET dsOrder BY-REFERENCE).
DYNAMIC-FUNCTION("detachDataSet" IN hSourceProc, hDataSet).
END PROCEDURE. /* saveChanges */
This wrapper procedure attaches the Data-Sources and event handlers, runs commitChanges.p, and then detaches the Data-Sources. This could as easily be incorporated directly into a procedure like commitChanges if it knows where to run the attach and detach methods. Beyond that, having a wrapper procedure gives the specific object an opportunity to add special commit logic before or after the standard code.
