The biggest strength of the client dataset lies in its ability to hold the original as well as modified data in memory and post the changes to the data source in a single transaction. Cache updates not only enhance performance by reducing network traffic, but in case of errors it makes rollback easy since the changes have not been committed. To understand how exactly the client dataset caches data we need to examine the structure of the dataset.The client dataset contains two data stores, Data and Delta. Data is the data store that contains the current data in memory and Delta contains a record of changes made to Data. When a record has been inserted into or deleted from Data, Delta contains a corresponding record; however, if a record has been modified, Delta contains two records for each record modified in Data. The first record represents the original record before it was modified and the second record contains field-by-field changes made to the original record. This helps in making the rollback process easy, since the transaction has not been committed and all updates have been cached locally. To use cache updates with the client dataset, you first need to add a Provider to enable the client dataset to fetch data from the data source and assign it to its data property.
This can be done by using the dataset provider with the client dataset to associate it with another dataset or use SQL statements or StoredProcedures in its command text property. The retrieved records are stored in the data property of the client dataset. When you edit/insert/delete records a corresponding record (two records in case of data modification) is created in the ChangeLog or the delta property of the client dataset. Unlike other datasets the client dataset does not commit changes to the records instantly and automatically. Instead, it keeps track of the changes and updates the data source only when the user specifies it should by calling the ApplyUpdates method.
Even when calling this method, the programmer has the liberty of specifying how many errors should be permitted when updating changes to the data source. This helps you control where exactly you want to roll back the transaction in case of specific errors. Applying updates is discussed in detail later in this series.
Cached updates or saving changes to records locally and committing them in a single transaction is supported by many datasets, but no dataset gives you as much control over data transaction, including cached updates, as the client dataset. It is the only dataset that allows you to successfully update Master/Details tables and nested tables from cache. It allows you to not only resolve changes to the data source but also reconcile data for records that encountered errors and were returned by the provider after the transaction. I will show you how to use the Reconcile Error dialog box later in this series. For the time being let us take a look at the demerits of client dataset.
One of the biggest drawbacks of the client dataset is that, since it stores data in cache, it may not represent the current server data. There is always a probability that while you are working it, another user may change the records, but this won't be reflected in the client dataset. You could then be left working with data that no longer exists in the data source. This can lead to lots of complications during the update process.
Another drawback with the client dataset which I learned the hard way is that you need a large amount of memory, because it caches data locally. Even this can be managed by specifying a maximum number of records that should be fetched using the PacketRecord and FetchOnDemand properties of the ClientDataSet component, but if the data contains BLOBs of considerable sizes I doubt if a standard desktop's resources would be sufficient to bring out the performance the client dataset is designed to provide.
However, the benefits of the client dataset outweigh its drawbacks. A client dataset can be used to create file-based database applications, two-tiered applications and multi-tiered applications. In a file-based application the client dataset loads and saves data to a file and does not require connection to a database server. In a two-tiered application the client dataset uses the TDatasetProvider component to connect to the data source. The Dataset Provider in its turn needs to be linked to a database server, another dataset or an XML document. The client dataset in a multi-tiered application is used to represent data in the client part of the application and needs to connect to an external provider to apply updates cached locally.
In this article an attempt was made to give you an overview of the client dataset component, its biggest strengths and major drawbacks and how it can be used in different application architectures to enhance their performance. The next few articles will focus on how to use the client dataset in different application development architectures and will, in the process, expose you to different methods and properties of the TClientDataset class.
