Demystifying the Client Dataset - Introducing the Client Dataset

(Page 2 of 4 )

The Client Dataset is a descendant of a TDataset class and inherits most of its methods and properties. At the same time it introduces a few of its own methods and properties. It holds data in memory in a table-like format and allows you to manipulate data in the same manner as you would manipulate it using a table-type dataset connected to a database server. But it can also be used as a query-type dataset by specifying SQL statements or stored procedures through its CommandText property. This flexibility of the client dataset in allowing itself to be used as a table-type dataset, a query-type dataset and a storedprocedure-type according to the situation, and even executing SQL statements that do not return a result, make it a very powerful accessory in database application development.

The Client Dataset component also allows you to create database applications that do not require connection to a database server or applications which are not absolutely dependent on data access mechanisms. Unlike other datasets, the client dataset does not connect to the database server itself but receives data from and sends data to internal and external providers. This provider can be a dataset provider in the same application or a dataset provider residing in a different application (in the case of multi-tier applications) or an XML provider.

In fact, you can also use the client dataset to create a database application which writes data to a flat file and loads it to memory when required. This is called MyBase, the ability of client datasets to save themselves to a file and to load the data from a file. I will come back to that later in this series; for now let us concentrate on the merits and demerits of the client dataset.

When using MyBase or a provider to transact data, the client dataset is supremely unconcerned about the data access mechanism being used for data transaction. This means that while coding you do not have to code keeping BDE, ADO or dbExpress in mind. When you are working with data, the client dataset stores all edited and unedited data locally and when the changes are committed, it passes those changes to the provider. When working with server data, the client dataset isolates the user from the database server for the most part. The user does not interact with data until s/he is committing the final transaction.

As such you don't have to worry about what data access mechanism is being used. In fact you don't even have to consider whether or not a particular feature is supported by the data access mechanism; you can implement it through the client dataset. This feature of not depending upon specific data access mechanisms makes applications built with the client dataset easy to migrate to other platforms and lets you change data access mechanisms without requiring significant rework.

Next: Using Filters and Ranges with the Client Dataset >>
 

More Delphi-Kylix Articles
More By Danish Ahmed

Comments On: Demystifying the Client Dataset

>>> Be the FIRST to comment on this article!