To use cached updates, the following order of processes must occur in an application: 

Indicate the data you want to edit. How you do this depends on the type of client dataset you are using:

• If you are using TClientDataSet, Specify the provider component that represent the data you want to edit.
• If you are using a client dataset associated with a particular data access mechanism, you must
• Identify the database server by setting the DBConnection property to an appropriate connection component.
• Indicate what data you want to see by specifying the CommandText and CommandType properties. CommandType indicates whether CommandText is an SQL statement to execute, the name of a stored procedure, or the name of a table. If CommandText is a query or stored procedure, use the Params property to provide any input parameters.
• Optionally, use the Options property to indicate whether nested detail sets and BLOB data should be included in data packets or fetched separately, whether specific types of edits (insertions, modifications, or deletions) should be disabled, whether a single update can affect multiple server records, and whether the client dataset's records are refreshed when it applies updates. Options is identical to a provider's Options property. As a result, it allows you to set options that are not relevant or appropriate. For example, there is no reason to include poIncFieldProps, because the client dataset does not fetch its data from a dataset with persistent fields. Conversely, you do not want to exclude poAllowCommandText, which is included by default, because that would disable the CommandText property, which the client dataset uses to specify what data it wants. For information on the provider's Options property, see Setting options that influence the data packets.

Display and edit the data, permit insertion of new records, and support deletions of existing records. Both the original copy of each record and any edits to it are stored in memory.This process is described in Editing data. 

Fetch additional records as necessary. By default, client datasets fetch all records and store them in memory. If a dataset contains many records or records with large BLOB fields, you may want to change this so that the client dataset fetches only enough records for display and re-fetches as needed. For details on how to control the record-fetching process, see Requesting data from the source dataset or document. 

Optionally, refresh the records. As time passes, other users may modify the data on the database server. This can cause the client dataset's data to deviate more and more from the data on the server, increasing the chance of errors when you apply updates. To mitigate this problem, you can refresh records that have not already been edited. See Refreshing records for details. 

Apply the locally cached records to the database or cancel the updates. For each record written to the database, a BeforeUpdateRecord event is triggered. If an error occurs when writing an individual record to the database, an OnUpdateError event enables the application to correct the error, if possible, and continue updating. When updates are complete, all successfully applied updates are cleared from the local cache. For more information about applying updates to the database, see Updating records. 

Instead of applying updates, an application can cancel the updates, emptying the change log without writing the changes to the database. You can cancel the updates by calling CancelUpdates method. All deleted records in the cache are undeleted, modified records revert to original values, and newly inserted record simply disappear.