Theoretically, native will offer better performance than ODBC.  But unless your app is extremely demanding you may not notice difference.

Another benefit of not using ODBC is you can take advantage of SQL Server-specific functionality.

Most customers use the native SQL Server client.  But Microsoft is no longer enhancing this.  So we are working on supporting SQLOLEDB driver.

In the interim, you can continue use ODBC, but eventually we recommend switching to the SQLOLEDB driver.

Hey, don't forget database error handling probably needs revision when you migrate from one DBMS + DB driver to another.

With ODBC you have two sets of error codes:

• SQLDBCode - property of SQLCA (transaction class) which contains DBMS specific error codes
• SQLSTATE - part of error message (property = SQLErrText) - standardized across ODBC drivers.

If your app processes SQLSTATE you may have less migration work for error handling when your aoo remains using ODBC since MSSQL in most cases produces same SQLSTATE values as DB2.

However, if your app like most apps I have seen processes SQLDBCode then you won't see such benefit from remaining on ODBC.

look at microsoft for their db2 migration documentation.

you need to review any sql you have for db2 specific functions and/or outer join processing.  the more ansi standard everything is, the less you will have to change.

for example coalesce is the ansi standard so you are good if you used that with db2.  but maybe it has a different function to do the same thing? (for example oracle uses nvl, i have no idea what db2 may have used, isnull() is sql server's 'old coalesce')