Client Dataset: Working with Data Packets and Applying Updates - Specific Fields and Custom Information
(Page 4 of 4 )
Including specific fields and adding custom information to data packets
You can specify the dataset provider to include specific fields only when creating data packets. This can be done by creating persistent fields in the associated dataset. The dataset provider then includes only these fields to build data packets. When the client dataset receives data packets with included dynamic fields, it treats them as static read-only fields. When the client dataset edits data and applies updates, you should always remember to include enough fields to make a record unique. If you want to hide these extra fields from the client dataset, set the ProviderFlags properties of these fields to pfHidden.
Another good feature that the dataset provider offers is the ability to add custom information to data packets. This can be done using the dataset provider's OnGetDataSetProperties event. The custom information is encoded into an OleVariant and is saved under whatever name you choose. When you add custom or application-specific information on the OnGetDataSetProperties event, each individual attribute or "optional parameter" is specified using Variant arrays consisting of three elements: name, value, and a boolean flag, which indicates whether this information will be included in the data packets sent to the server for update. The client dataset can retrieve this information using its GetOptionalParam method.
Before posting data to the database, the dataset provider generates an OnUpdateData event whose handler receives the Delta packet as a parameter.
procedure TForm1.DataSetProvider1UpdateData(Sender: TObject;
DataSet: TCustomClientDataSet);
You can examine and edit this dataset using the methods of the client dataset before it is written to the database. To determine the kind of modification the records have undergone, you can use the UpdateStatus property of the dataset. If the UpdateStatus returns "usInserted," then the record has been inserted. If it returns "usModified," then it reflects that the record has been modified. If the record has been deleted, the UpdateStatus would be returned as "usDeleted" and if the return is "usUnmodified," then it implies that the record has not been modified. The UpdateStatus mode can be used to determine the state of records and deal with them accordingly.
You can restrict and control the records that are sent to the database by using the UpdateMode property of TBaseProvider. Since the updates are saved to database using SQL UPDATE, INSERT, and DELETE statements, you can assign specific values to the UpdateMode property in order to selectively include non-BLOB fields in the WHERE clause. The UpdateMode property is set to upWhereAll by default and includes all the fields of the record. To include only those fields that have been modified, set the UpdateMode property to upWhereChanged. The upWhereKeyOnly option includes only the primary key fields in the WHERE clause of the SQL statement.
Delphi provides you with more control over the transaction if you are using the client dataset and the dataset provider. You can also instruct the provider to include fields specifying the values of their ProviderFlag property. If a field's ProviderFlag is set to pfInWhere , the field is included in the SQL statement in the WHERE clause. It also requires the UpdateMode to be set to upWhereAll or upWhereChanged.
To include a field in UPDATE SQL statements, set its provider flag to pfInUpdate. And to include key fields in the WHERE clause of the SQL statement, set its provider flag to pfInKey. This also requires that the UpdateMode is upWhereKeyOnly. You can also set a field's ProviderFlag property to pfHidden so that it is included in the update SQL statement, but is not visible on the client side. This feature is useful and should be used to ensure the uniqueness of the record, especially when creating and using persistent fields in the client dataset to send selected fields as update.
As mentioned earlier, when the client dataset calls the ApplyUpdates method, the delta packet is sent to the dataset provider. This delta dataset is a client dataset too, which means that it contains both the original data and the modified data and is editable. You can edit this dataset in the BeforeUpdateRecord event of the dataset provider. This event can be used to screen individual record updates by working directly with the data. For every record that is to be inserted, this dataset contains only the new value and for those that are to be deleted, it contains old values only. But for records that have been modified, this dataset contains two records: the original and the modified record. To access the original data you can use the OldValue property of the DeltaDs' field object. And to access the edited value, use NewValue property.
DeltaDs.Fields[1].OldValue;
DeltaDs.Fields[1].NewValue;
or
DeltaDs.FieldByName('fName').OldValue;
DeltaDs.FieldByName('fName').NewValue;
Note: While editing records after the ApplyUpdates method has been called, you should not call any methods that change the current record.
Before ending I should mention that yet another merit of the client dataset that I have not mentioned at all is the fact that it can also be used to create a briefcase model application by combining the file-based architecture with n-tier architecture. The client dataset in this application allows you to work in offline mode and updates the data source when you switch to online mode. I will discuss this architecture and the role the client dataset plays in it in some future article.
Danish Ahmed
http://www.mindfiresolutions.com/
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
