VB Migration Partner


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:

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 

Follow Francesco Balena on VB6 migration’s group on


Read Microsoft Corp’s official case study of a VB6 conversion using VB Migration Partner.

Code Architects and its partners offers remote and onsite migration services.

More details

Subscribe to our free newsletter for useful VB6 migration tips and techniques.


To learn more about your VB6 applications, run VB6 Analyzer on your source code and send us the generated text file. You will receive a detailed report about your VB6 applications and how VB Migration Partner can help you to quickly and effectively migrate it to .NET.

Get free advice

A fully-working, time-limited Trial Edition of VB Migration Partner allows you to test it against your actual code

Get the Trial

The price of VB Migration Partner depends on the size of the VB6 application, the type of license, and other factors

Request a quote

Migrating a VB6 application in 10 easy steps

Comparing VB Migration Partner with Upgrade Wizard

Migration tools: Feature Comparison Table

All whitepapers