Hi Larry;

Appeon typically focuses our testing on "native" DBMS drivers. ODBC is part of a group of software that the IT industry calls "middle-ware". In the case of ODBC, you have some Microsoft code plus the DBMS vendors code (ODBC driver) running in the middle between your PB (or any App - C#, Delphi, C++, Python, etc) and the DBMS. Appeon does test the ODBC "interface" PB driver for ODBC "compliance" however, it does not test the DBMS vendor's drivers that sit between the ODBC "Manager" and the DBMS itself.

Your situation is more complicated because of using "middle-ware" - in this case ODBC. PB wants to efficiently convert a PBSelect into a native ANSI based DML commands for the DBMS its connected to. However, at run-time, it will see that your using ODBC and then generate "ODBC SQL" format instead. .The ODBC layer then hands the ODBC SQL to its Oracle DB driver who then converts the ODBC SQL to PL-SQL (in your case). On the way back from the DBMS, PB normally expects a binary result set (in the DBMS's flavour). However, the Oracle RS, is sent back to the ODBC/Oracle driver, who in turn converts this into an ODBC result set format. The ODBC Manager in turn, hands that to the ODBC driver & PB DB interface - which in turns converts the ODBC result set into a proper ANSI format (which PB was expecting from any DBMS in the first place. So in the long & short of it, any "middle-ware" DB connection will never be as DML robust or performance minded as a native driver. So you may have to refactor some of of your App's SQL because of this "middle-ware" architecture. Then its important to thoroughly test your App(s) for performance changes.

Regards ... Chris