This article was previously published under Q190717
This article has been archived. It is offered "as is" and will no longer be updated.
With the introduction of the Advanced Data Connector (later renamed theRemote Data Services of ActiveX Data Objects [ADO]), it is possible tocreate a disconnected recordset. In addition, the Distributed ComponentObject Model (DCOM) allows you to marshall COM objects across computerboundaries, providing similar (but not identical) functionality to RemoteData Service (RDS).
This article describes what a disconnected recordset is and the differencesin implementation.
Disconnecting a recordset means you can view the recordset's data aftersevering the connection to the data store that generated the recordset. Youcan create a disconnected ADO recordset in process with a recordset whoseCursorLocation property is adUseClient and whose ActiveConnection propertyis set to NULL/Nothing. You can then pass this recordset to a remote clientusing either RDS or DCOM (or both together).
In ADO, you generate the recordset normally, as you would any otherrecordset, then disconnect it from the connection by setting theRecordset.ActiveConnection property to NULL/Nothing. Then you can close theConnection object.
In RDS, you generate an ADO recordset by requesting it through the use ofRDS client components.
Techniques to Pass Disconnected Recordsets
There are four techniques you could use to pass a disconnected recordset toa remote client.
The first technique requires a server running Internet Information Server(IIS) 3.0 or later, and RDS Server components 1.5 or later. A client usingRDS client components (Msador15.dll and other DLLs) sends a request byusing one of three protocols, HTTP, HTTPS, or DCOM, using one of three RDSobjects to initiate the request. (NOTE: If you are using DCOM, it is notstrictly necessary to have IIS, but IIS is required for HTTP or HTTPS). Theserver then generates a recordset and marshals it to the client. There isonly one round trip between server and client when using RDS for either theHTTP protocols or DCOM. RDS uses the client cursor engine to supportoperations on a then-disconnected recordset. Changes can be made andsubmitted back to the server. The server has a business object, whichgenerates the recordset and optionally receives changes to that recordset.You can use the default RDS business object, RDSSERVER.DataFactory, or youcould use your own ActiveX DLL. For more information, please see theMicrosoft Knowledge Base article listed in the REFERENCES section.
You do not need to have ADO installed on the client (or OLE DB or anyproviders or ODBC drivers), just the RDS client components. In thisscenario, you are using an ADO recordset (as offered by Msador15.dll), butcompletely disconnected from the server.
The second technique borrows heavily from the first, except that instead ofusing RDS client components to generate an ADO recordset, you use the ADOConnection object and specify connection information, which uses the RDSserver components to return the recordset.
For more information, please see the Microsoft Knowledge Base articlelisted in the REFERENCES section.
The third technique is to use DCOM to marshal the recordset from a serverto a client. This can be accomplished either by using DCOM directly or fromwithin a business object running under Microsoft Transaction Server. Thereare two samples that will be useful for you. One uses DCOM (without ADO)and the other uses DCOM, ADO, and Microsoft Transaction Server. Between thetwo, you should be able to implement a DCOM solution that works for you.
Note that DCOM itself does not fetch and return data in just one round tripas RDS does even using DCOM. That is, the recordset is not sent down in onebatch, but in repeated roundtrips between the server and remote clientapplication. In this respect RDS is more efficient and imposes a smallernetwork performance hit.
The fourth and final technique is possible with a new feature in ADO 2.0.With ADO 2.0 it is possible to save and later retrieve an ADO recordset.This allows you to persist data remotely, or even put it on a disk andcarry it in your pocket! The Anomaly Tracking System shipping with VisualStudio 98 uses this feature heavily. For more information, consult the DataAccess SDK 2.0 documentation for ADO, specifically the Recordset Open andSave methods.
The Whitepaper "What's New in ADO 2.0?" discusses this and other newfeatures in ADO 2.0. After September 1st, 1998, there will be acorresponding set of samples written in Visual Basic, Visual C, and VisualJ++ that demonstrates each of the code Visual Basic snippets found in thisWhitepaper. For more information, please see the following Web address:http://msdn.microsoft.com/library/
You can download Data Access SDK 2.0 from the following Web site: