No COM synchronization takes place as ADO is thread-safe and does all of the necessary synchronization. Overall, this means that ADO does no COM marshaling for the in-process scenarios. Beyond Standard Marshaling ADO's standard marshaling is sufficient for many scenarios but not all. For example, standard marshaling across processes can hurt performance because for each call to the ADO object, an application is making a call across process. It would be better for performance if all of the data of a recordset was returned to the client and then any subsequent calls such as fetching were made locally in the client rather than back to the COM server where the recordset was created.
ADO provides such a mechanism for the recordset object.
To return a recordset object from a server and have the data of the recordset marshaled to the client, you specify adUseClient for the recordset's CursorLocation property. The adUseClient value tells the recordset object to use the Client Cursor Engine which caches all of the records of the recordset. The database connection is not carried along with the recordset data when adUseClient is specified. With adUseClient set, you always pass the data of the recordset when sending the recordset across process. The newly created ADO recordset object in the receiving process simply attaches to the recordset stored in the client cursor engine cache.