INFO: Disconnected Recordsets with ADO or RDS

ID: Q190717

The information in this article applies to:

ActiveX Data Objects (ADO), versions 1.0, 1.5, 2.0
Remote Data Service for ADO versions 1.0, 1.1, 1.5, 2.0

SUMMARY

With the introduction of the Advanced Data Connector (later renamed the Remote Data Services of ActiveX Data Objects [ADO]), it is possible to create a disconnected recordset. In addition, the Distributed Component Object Model (DCOM) allows you to marshall COM objects across computer boundaries, providing similar (but not identical) functionality to Remote Data Service (RDS).

This article discusses what a disconnected recordset is and the differences in implementation.

MORE INFORMATION

Disconnecting a recordset means you can view the recordset's data after severing the connection to the data store that generated the recordset. You can create a disconnected ADO recordset in process with a recordset whose CursorLocation property is adUseClient and whose ActiveConnection property is set to NULL/Nothing. You can then pass this recordset to a remote client using either RDS or DCOM (or both together).

In ADO, you generate the recordset normally, as you would any other recordset, then disconnect it from the connection by setting the Recordset.ActiveConnection property to NULL/Nothing. Then you can close the Connection object.

In RDS, you generate an ADO recordset by requesting it through the use of RDS client components.

Techniques to Pass Disconnected Recordsets

There are four techniques you could use to pass a disconnected recordset to a 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 using RDS 1.1 client components (Msador15.dll and other DLLs) sends a request by using one of three protocols, HTTP, HTTPS, or DCOM, using one of three RDS objects to initiate the request. (NOTE: If you are using DCOM, it is not strictly necessary to have IIS, but IIS is required for HTTP or HTTPS). The server then generates a recordset and marshals it to the client. There is only one round trip between server and client when using RDS for either the HTTP protocols or DCOM. RDS uses the client cursor engine to support operations on a then-disconnected recordset. Changes can be made and submitted back to the server. The server has a business object, which generates the recordset and optionally receives changes to that recordset. You can use the default RDS business object, RDSSERVER.DataFactory, or you could use your own ActiveX DLL. For more information, please see the Microsoft Knowledge Base article listed in the REFERENCES section.

You do not need to have ADO installed on the client (or OLE DB or any providers or ODBC drivers), just the RDS client components. In this scenario, you are using an ADO recordset (as offered by Msador15.dll), but completely disconnected from the server.

The second technique borrows heavily from the first, except that instead of using RDS client components to generate an ADO recordset, you use the ADO Connection object and specify connection information, which uses the RDS server components to return the recordset.

For more information, please see the Microsoft Knowledge Base article listed in the REFERENCES section.

The third technique is to use DCOM to marshal the recordset from a server to a client. This can be accomplished either by using DCOM directly or from within a business object running under Microsoft Transaction Server. There are two samples that will be useful for you. One uses DCOM (without ADO) and the other uses DCOM, ADO, and Microsoft Transaction Server. Between the two, 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 trip as RDS does even using DCOM. That is, the recordset is not sent down in one batch, but in repeated roundtrips between the server and remote client application. In this respect RDS is more efficient and imposes a smaller network 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 and carry it in your pocket! The Anomaly Tracking System shipping with Visual Studio 98 uses this feature heavily. For more information, consult the Data Access SDK 2.0 documentation for ADO, specifically the Recordset Open and Save methods.

The Whitepaper "What's New in ADO 2.0?" discusses this and other new features in ADO 2.0. After September 1st, 1998, there will be a corresponding set of samples written in Visual Basic, Visual C, and Visual J++ that demonstrates each of the code Visual Basic snippets found in this Whitepaper. For more information, please see the following Web address:
http://msdn.microsoft.com/library/

REFERENCES

The Data Access SDK 2.0 can be downloaded from the following Web site:

http://www.microsoft.com/data/download.htm

The "Whats New in ADO 2.0" whitepaper can be obtained from the following Web site:

http://msdn.microsoft.com/library/

For additional information, please see the following articles in the Microsoft Knowledge Base:

Q183609 FILE: Rdsvb.exe Demonstrates How to Use RDS with Visual Basic

Q183628 HOWTO: Using the RDS DataFactory via Standard ADO Open Method

Q182442 FILE: Adomts.exe Shows Using ADO w/ an MTS component via DCOM

Q175510 FILE: VB5DCOM.EXE: Using Callbacks and WithEvents with DCOM

Additional query words: kbrds kbADO100 kbADO150 kbADO200 kbADO201 kbRDS100 kbRDS110 kbRDS150 kbRDS200 kbDCOM


Keywords          : kbADO100 kbADO150 kbADO200 kbDatabase kbRDS100 kbRDS110 kbRDS150 kbRDS200 kbVBp600FAQ 
Version           : WINDOWS:1.0,1.1,1.5,2.0
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: July 20, 1999