The OpenEdge ProDataGraph provides built-in support for tracking updates with its ProChangeSummary object. This object keeps track of what rows are changed (modified, added, or deleted) in the ProDataGraph and also keeps track of the original versions of modified or deleted rows so you can compare those rows against the current rows. For more information on the ProChangesSummary object, see ProChangeSummaryclass. In the procedure that follows, this and other OpenEdge support facilitates management of the ProDataSet update cycle in a Java Open Client application.
To manage a ProDataGraph through an update cycle:
1. Receive your working ProDataGraph as an OUTPUT parameter of the application service. For more information, see Passinga ProDataGraph as OUTPUT.
Note: While the actual parameter passing mode is application service dependent, an OUTPUT parameter is typical for an OERA-compliant application.
2. Make changes to the ProDataGraph on the client, as follows:
Note: Because the application service sees the changes in its input ProDataSet using before-tables, all temp-tables subject to update are defined on the AppServer using the BEFORE-TABLE option. To verify that a temp-table whose data you plan to update is defined with this option, you can check the boolean value returned from the getBImageFlag() method on the ProDataObjectMetaData that corresponds to this temp-table. If the value is true, you can update the corresponding ProDataObject collection and the application service can handle the updates.
3. Return the ProChangeSummary object from your working ProDataGraph using the following ProDataGraph method:
Syntax
ProChangeSummary getProChangeSummary()
4. Extract a separate changes-only ProDataGraph from your working ProDataGraph using the following ProChangeSummary method:
Syntax
ProDataGraph getChanges()
5. Pass the changes-only ProDataGraph back to the application service using an INPUT-OUTPUT parameter. This allows the results to be passed back to the client in the same parameter.
Note: While the actual parameter passing mode is application service dependent, an INPUT-OUTPUT parameter is typical for an OERA-compliant application.
6. Process the results from the application service in the output of the changes-only ProDataGraph that you passed to the AppServer in Step 5. This ProDataGraph now contains any additional changes, including errors, returned from the AppServer, as follows:
a. Handle any errors that might be returned for each ProDataObject as well as the ProDataGraph as a whole. For more information on checking errors, see Checkingfor errors.
b. Check the final changes in the output changes-only ProDataGraph using the methods of its ProChangeSummary object. For more information, see ProChangeSummaryclass. Compare the changed rows to the corresponding row in your working output ProDataGraph. Update the original row and add or delete additional required rows as described in Step 2.
7. Once you have merged all final changes into your working ProDataGraph in Step 6, use the following method to accept all changes in the ProDataGraph:
Syntax
void acceptChanges()
This clears out the list of changes in the ProChangeSummary of your ProDataGraph, allowing it to accept more changes.
8. Delete the changes-only ProDataGraph from Step 5 and Step 6.
9. Update any UI appropriately for your updated working ProDataGraph.
10. You can now accept more changes to the working ProDataGraph, as in Step 2, restarting the update cycle, again.
For information on finding rows in a ProDataGraph, see Findinga row in a ProDataGraph.