The known issues fall into three major categories:
Because of a problem with the way MDAC 2.6 stores bookmarks internally, only the first row of a recordset will be returned when you use the MoveNext method to iterate through a recordset. The Microsoft Knowledge Base article Q273791 recommends using MDAC 2.5 or installing the next MDAC 2.6 Service Pack as soon as it is available. If you cannot use MDAC 2.5 and the MDAC 2.6 Service Pack is not available, you can use one of the following alternatives:
Alternative 1
RecordSet.Move 1, 0
Alternative 2
RecordSet.Move 1, adBookmarkCurrent
To set a customized rowset property on an ADO Recordset object, you set the property value on a Command object that is associated with an open connection, and then use the Command object to open the Recordset object. Following are the basic steps to perform this task:
obConnection.Open "Provider=provider_name;Data Source=data_source"
Set obCommand.ActiveConnection = obConnection
obCommand.CommandText = "data_set_identifier"
obCommand.Properties("property_name") = property_value
obRecordset.Open obCommand, , CursorType, LockType, adCmdTableDirect
Note: If you are using MDAC 2.5 or later, you do not need to use this workaround. The following topics contain information about setting customized rowset properties: Opening a Password-Protected Data Set and Padding Character Data with Blanks.
When a server-side cursor is used, the following two properties cannot be accessed through the ADO interface from an ASP page:
The "Literal Row Identity" property is read-only and therefore has a minor impact on the functionality of the providers. The value of the "Literal Row Identity" property is always VARIANT_TRUE.
The absence of the "IRowsetUpdate" property, however, may result in unexpected behavior. By default, the "IRowsetUpdate" property is VARIANT_FALSE, meaning that recordsets are opened in immediate update mode. This also means that batch updating (via the UpdateBatch method) will not be available when a server-side cursor is used. These properties are available in Visual Basic applications for both server-side and client-side cursors, as well as in ASP pages when using a client-side cursor. For more information about cursor types and locations, see Supported ADO Cursor and Lock Type Combinations.
If your application uses an ADO client-side cursor, you will see the following error when the application attempts to access SAS customized properties: "Item cannot be found in the collection corresponding to the requested name or ordinal." This problem applies to the ADO Connection object and the ADO Recordset object and occurs because ADO does not request information about properties from the provider when a client-side cursor is used.
To enable the application to access SAS customized properties:
The data binding features of the Visual Basic DataBound Controls cannot be used reliably with the SAS OLE DB Providers. Do not use these controls with the providers.
The following ADO Recordset methods will fail with Version 7 compressed data sets when the number of records to move is non-zero: Move, MoveNext, MoveFirst, and MovePrevious. In this situation, these methods result in random access operations, which are not supported in compressed SAS data sets prior to Version 8.
In SAS Version 8, when a compressed SAS data set is created with the options POINTOBS=YES and RESUSE=NO (which are the default values), the data set can be accessed randomly, and the Move, MoveNext, MoveFirst, and MovePrevious methods will be successful.
The SAS IOM Data Provider does not currently implement the ADO "MaxRecords" property.
For character fields, the "DefinedSize" property is set to the maximum number of characters defined for that field. Because the IOM provider returns character data as wide character strings, the size of this field in bytes is twice the value of "DefinedSize." To get an accurate size in bytes, you must multiply "DefinedSize" by 2.
Note: The "ActualSize" property correctly returns the length in bytes.
When ASP pages served from a machine running Windows 2000 Professional attempt to connect to an IOM server on the same machine using COM, all Recordset objects will report EOF immediately after being opened as if the recordsets contain no rows. This behavior only occurs under Windows 2000 Professional. In addition, you will not encounter this problem if the ASP page server and the IOM server are on different machines. As a workaround, use the dcomcnfg tool to change the "Authentication Level" of the "SAS: IOM DCOM Servers" to "(None)". For more information about using dcomcnfg, read the topic on turning off call security, which can be found in the Microsoft Developer Network Platform SDK documentation on the Microsoft Web site by following this path.
| MSDN July 2001 | MSDN Online |
|---|---|
|
|
When you use the OLE DB property "DBPROP_SAS_INIT_FILEFORMAT" (the ADO property "SAS File Format") and specify a value of "V8", the local provider does not properly convert numeric variables for SAS data sets created on non-Windows platforms. In this case, the local provider returns incorrect data for the numeric variable (although it does not return an error).
To ensure that numeric variables are converted properly for non-Windows SAS data sets, use the default file format or "V9".
For more information, see How the Local Provider Provides Cross-Platform Support.
If you use the read-only Local Data Provider to open a Recordset object with a server-side cursor, ADO will attempt to read the values of the DBPROP_IRowsetUpdate and DBPROP_IRowsetChange properties. If both of these properties are false, the following Visual Basic statements will return FALSE:
In this case, any attempt to update the Recordset will result in an error message that says: "Object or provider is not capable of performing requested operation." This response is consistent with a read-only provider.
However, when a Recordset object is opened with a client-side cursor, ADO does not ask the provider for the values of DBPROP_IRowsetChange and DBPROP_IRowsetUpdate. In this case, all four of the Visual Basic statements listed above will incorrectly return TRUE, which makes it appear as if the opened recordset can be updated. If you attempt to perform the update, you will see this error message: "Multiple-step operation generated errors. Check each status value."
If you use the Local Data Provider to read transport files, you will encounter a movement limitation. The engine used to read transport files is a forward-only sequential single pass, which means that you can make only one pass through the file. As a result, OLE DB Rowset RestartPosition method and the ADO Recordset MoveFirst method are unsupported for the transport file format. When using OLE DB, you must close and then reopen the file to reposition the cursor at the first row. When using ADO, you must close and then reopen the Recordset to reposition the cursor at the first row.