Persistence Provider Implementation Scenarios

Saving Rowset Data

The Persistence Provider can be used to save rowset data to a local file. After your application has opened a recordset, it calls your provider and saves the data. Saving the rowset creates an instance of the Persistence Provider so that the rowset data. together with the metadata and state information, can be written to the specified file. After the data is in this persisted state, the connection to the original data store is no longer needed.

Loading Persisted Rowset Data

When data from the original data store has been saved to a file on your computer, the Persistence Provider can be used to load that data into your application for viewing or modifying. For the load process, your application opens an unpopulated recordset and identifies the specific local file. Next, behind the scenes, the Persistence Provider is created to load the persisted data into the Cursor Service. The Cursor Service is an OLE DB service component that allows the application to manipulate the loaded rowset. After the rowset has been wrapped in a recordset, its state information and metadata are exposed.

Persistence Provider with Remoting

The Persistence Provider can be used in a remote configuration that allows you the same functionality as the Load and Save scenarios. When the Refresh method or the SubmitChanges method is invoked on the RDS.DataControl object, the Persistence Provider is created and called automatically behind the scenes. The object can be used to directly create ADO recordsets from remote OLE DB providers without writing any code. It implements methods and properties that can be manipulated directly at both design time and run time, through HTML or through scripting, to create and update disconnected ADO recordsets. RDS.DataControl always invokes the DataFactory component on the server.

Calling the Refresh method sends the requested query through the local Remoting Provider. This provider then streams the data (specifically, the request) over a DCOM or HTTP protocol to the server's Remoting Provider. The local Remoting Provider then waits for a response from the server.

The DataFactory component of the server, in essence, manages the rowset on the remote machine: It calls your provider with the requested query, loads the rowset into the server copy of the Cursor Service component (caching the rowset data), and calls the server's image of the Persistence Provider. The connection to the data store at this point is no longer necessary. The Persistence Provider then streams the data back over the network to the waiting Remoting Provider.

After the local copy of the Remoting Provider receives the response and rowset data from the server, the rowset can be loaded into the client Cursor Service and made available to the application as described in the preceding section on "Loading Persisted Rowset Data." the connection to the server can be dropped.

To submit changes made to a recordset by the application, the process is reversed. SubmitChanges is called to persist the rowset through the local copy of the Remoting Provider into a stream over the network. The server-side Persistence Provider receives the stream where the DataFactory passes the data as an argument to your provider in order to update the data store.

This topic is a part of:

• OLE DB Persistence Provider