Many existing native applications can be compiled as managed applications simply by changing the compiler directive option from ODBC to ADO. For these applications, performance characteristics and storage requirements might differ.
For example, any cursor used for scrolling fetches or positioned updates has its result set read completely and buffered on the client system in a DataSet when it is opened. ADO.NET provides no native support for positioned updates and so OpenESQL converts them to searched updates using original column values and optimistic concurrency. For this to provide the same degree of integrity as ODBC, an application must use repeatable read transaction isolation and the result set must contain columns that will uniquely identify the row being updated.
It is also possible for a single application to include some programs compiled with each, but each of the programs included in the application must use one or the other, and each must specify a database connection that uses an appropriate DSN. You cannot share database connections and transactions between ODBC and ADO.NET.