Previous | Index | Next 

[INFO] Main ADOLibrary limitations

ADOLibrary doesn’t support all ADODB features. Here is the list of the main features that aren’t supported or are supported only partially:

  • Hierarchical recordsets aren’t supported.
  • Server-side cursors (other than forwardonly-readonly cursors) are supported only for Microsoft SQL Server databases.
  • Multiple, semicolon-delimited SQL statements are supported in Recordset.Open methods, but not in the Execute method of the Connection and Command objects.
  • Asynchronous execution is allowed for the Open method of Connection and Recordset objects, but not for the Execute method of the Connection and Command objects.
  • The SELECT statement used to open server-side keyset and dynamic cursors must include at least one non-nullable key column.
  • The Move method doesn’t work and raises an exception with serverside dynamic cursors.
  • The Index, Seek, MarshalOption, StayInSync members of the Recordset class aren’t implemented and are marked as obsolete.
  • The PageSize, Clone, and Find members of the Recordset class aren’t implemented for keysets and other server-side cursors.
  • The adExecuteNoRecords flag can’t be omitted in an Execute method when calling a stored procedure that doesn’t return any data row.
  • The CommandStream, Dialect, NamedParameters, and Prepared members of the Command class aren’t implemented and are marked as obsolete.
  • The ReadText, WriteText, and SkipLines methods of the Stream class aren’t implemented and are marked as obsolete.
  • A few dynamic properties of the Connection or Recordset objects aren’t supported.
  • The ADODB.Record class isn’t supported.

The Recordset.UpdateBatch method undergoes the following limitations:

This method works as in ADODB, except for the following details:

  • the SELECT statement must include the key/identity field of the table (or tables, if it’s a JOIN statement)
  • JOIN SQL statements are supported, provided that
    • the key/identity field of each table is included in the field list
    • if * is used to indicate “all fields”, then the joined tables must not have fields with same name; if necessary, alias names must be provided
    • old join syntax (e.g. SELECT * FROM Table1,Table2) isn't supported
  • all valid SQL syntax for table names are supported (e.g. database.dbo.table), except
    • field names and table names cannot include dots (even if names are included between square brackets or double quotes) o if a table name in the FROM clause is embedded in square brackets (or double quotes), then the same enclosing delimiters must be used if the table name is used a prefix for the field name. For example:
         SELECT [Order Details].OrderID FROM [Order Details] is supported
         SELECT [Order Details].OrderID FROM "Order Details" isn't supported
  • derivate tables aren't supported (e.g. SELECT * FROM (SELECT ....) ).
  • the UNION clause isn't supported.
  • if two UpdateBatch commands are issued on the same recordset and you need to modify one or more fields of a row that has been already batch-updated, it is necessary that you perform the following command after the first UpdateBatch and before modifying the fields: 
    myRecordset.DataTable.AcceptChanges()

When invoking a parameterized command, the SQL statement passed to the Command.CommandText property undergoes the following limitations:

    aliased columns are supported (e.g. "LastName AS LN"), but aliased expressions aren't (e.g. "SUBSTRING(title,1,10) AS Title").
  • aliased tables aren't supported.
  • derived tables aren't supported (e.g. "SELECT a.au_lname AS Name, d1.title_id FROM authors a, (SELECT title_id, au_id FROM titleauthor) AS d1").
  • parameters can't precede the BETWEEN keyword: for example “…WHERE fieldname BETWEEN ? AND ?” is supported but “... ? BETWEEN 10 AND 20” is not.
  • if the statement contains a nested SELECT, parameters can't appear both in the main WHERE clause and in the nested SELECT statements. (Parameters can correspond to fields belonging to different tables only if the tables appear in a JOIN.)

The following restrictions apply to INSERT SQL statements:

    the list of columns must be present (* isn’t allowed) and the VALUES keyword must be present.
  • parameters used in the VALUES can't appear in expressions (i.e. must be the only value assigned to a field).

The following restrictions apply to EXEC SQL statements and stored procedure invocations:

    parameters can appear in the list of stored procedure arguments, but can't be part of an expression. For example, "EXEC spname ?, '1abc', ?" is legal, but "EXE spname ?+12" is not.

 

Previous | Index | Next