PRB: Cannot Create ADO Recordset Hierarchies Manually (202912)
The information in this article applies to:
- ActiveX Data Objects (ADO) 2.0
- ActiveX Data Objects (ADO) 2.1
- ActiveX Data Objects (ADO) 2.5
- ActiveX Data Objects (ADO) 2.6
- ActiveX Data Objects (ADO) 2.7
This article was previously published under Q202912 SYMPTOMS
With Microsoft ActiveX Data Objects, you can programmatically create recordsets in memory using the Recordset.Fields.Append method. With the Recordset.Fields.Append method, you can create a field of type adChapter, adDispatch, adVariant, or adUnknown, and then later insert another manually created recordset into this field. This method can be used to manually create a hierarchical (or nested) recordset that appears to work in the same manner as a nested recordset returned by the SHAPE provider. This functionality appears to work properly but is actually not supported by ADO.
CAUSE
The recordset object stored inside of the field is stored as a IDispatch or IUnknown pointer, which works properly in an in-process COM environment. For example, an ADO recordset created in this manner cannot be marshalled over DCOM or HTTP with RDS because ADO does not provide functionality to marshal the internal IDispatch / IUnknown pointers stored inside of the fields. Also, if you close the master recordset without looping through each record and each field and explicitly release each nested recordset, you will leak the memory associated with the child recordset.
STATUS
This behavior is by design. ADO does not support the creation of recordsets in
this manner. ADO does not offer marshalling support for the internal recordset
pointers. Use of the adChapter, adDispatch, adVariant, and adUnknown fields
created using the Recordset.Fields.Append method is not supported by ADO and
can result in leaked memory and leaked interface pointers even when used
in process.
Modification Type: | Major | Last Reviewed: | 8/23/2001 |
---|
Keywords: | kbDatabase kbDSupport kbprb KB202912 |
---|
|