If you have written the application yourselves then using bound columns and large Array sizes is a great deal more efficient over a network. The OOB client pulls all the bound columns over in one go which is a lot quicker than using repeated SQLFetchs and multiple SQLGetData calls, one per column.
If you do not want to change your application (or cannot) and you are only reading data from the database (and not using positioned updates, deletes etc) then the OOB has a built in block-fetch-mode which may be enabled with the DSN attribute, BlockFetchSize. Add "BlockFetchSize = n" to the DSN entry you are using where (0 <= n < 100) n is the number of rows to retrieve in one go. This shows significant speed increases for the reasons in the paragraph above but may not be used with certain types of cursors and when doing positioned updates/deletes.
A value of 1 is safe to use even if you are doing positioned updates and deletes and is often faster than with block-fetch-mode turned off.
The OOB performs the following tests to decide whether BlockFetchMode is possible:
The MS SQL Server driver will not return RowsProcessedPtr to an ODBC 2.0 app.
Note from the above checks, BlockFetchSize has no effect when the application or interface is using bound columns itself to retrieve data (e.g. Perl's DBD::ODBC).
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.