Refreshing Records
Go Up to Passing Parameters to the Source Dataset
Client datasets work with an in-memory snapshot of the data from the source dataset. If the source dataset represents server data, then as time elapses other users may modify that data. The data in the client dataset becomes a less accurate picture of the underlying data.
Like any other dataset, client datasets have a Refresh method that updates its records to match the current values on the server. However, calling Refresh only works if there are no edits in the change log. Calling Refresh when there are edits that are not applied results in an exception.
Client datasets can also update the data while leaving the change log intact. To do this, call the RefreshRecord method. Unlike the Refresh method, RefreshRecord updates only the current record in the client dataset. RefreshRecord changes the record value originally obtained from the provider but leaves any changes in the change log.
Warning: It is not always appropriate to call RefreshRecord. If the user's edits conflict with changes made to the underlying dataset by other users, calling RefreshRecord masks this conflict. When the client dataset applies its updates, no reconcile error occurs and the application cannot resolve the conflict.
To avoid masking update errors, you may want to check that there are no pending updates before calling RefreshRecord. For example, the following AfterScroll refreshes the current record every time the user moves to a new record (ensuring the most up-to-date value), but only when it is safe to do so:
procedure TForm1.ClientDataSet1AfterScroll(DataSet: TDataSet);
begin
if ClientDataSet1.UpdateStatus = usUnModified then
ClientDataSet1.RefreshRecord;
end;
void __fastcall TForm1::ClientDataSet1AfterScroll(TDataSet *DataSet)
{
if (ClientDataSet1->UpdateStatus == usUnModified)
ClientDataSet1->RefreshRecord();
}