I tried to trace ODBC function calls from my program working on Linux. This program dynamically links ODBC manager and then connect to database and fetch some data.
I can trace ODBC calls with unixODBC by adding to odbcinst.ini:
[ODBC]
Trace=yes
TraceFile=/tmp/sql.log
This method is documented by IBM: Collecting data for an ODBC Problem
But when I change manager from unixODBC to Informix's own manager (libifdmr.so), the trace file is not created. Anybody successfully obtained ODBC trace from Informix manager (and driver) on Linux?
Client version: CSDK 3.50UC3
I hope that it is not a bug and something is wrong with my config.
As for unixODBC: I cannot use unixODBC in multithreaded app. I use connection pool and my app segfaulted when disconnection was from another thread than connection. It is also much slower in multithreaded app.
Best Answer
If you run:
do you get to see any references. If not, then the library is without the support functions. If you do see that, the mechanism outlined should work. If it doesn't, you probably have a reportable bug.
What level are you trying to trace the issues? And, since unixODBC works, why not use the driver manager that does work?
I've taken the example distsel.c from $INFORMIXDIR/demo/cli and compiled it on Solaris 10 using CSDK 3.50.FC3. I got it to the point where the connection succeeds, but the table 'item' is missing in the database I'm using, so the program stops SQLExecDirect(). When I run it under 'truss' (equivalent of 'strace' on Linux), then I see no evidence of the code even trying to open the trace file.
I compiled using:
I used the following .odbc.ini file:
And this one:
Consequently, I believe you have found a bug. I'm not sure whether the bug is in the FAQ you referenced or in the product - I'm inclined to think the latter. You should report the issue to IBM Technical Support. (I've not checked the Informix CLI (ODBC) manual; it might be worth checking that before trying to file a product bug; if the manual indicates that Trace doesn't work, and perhaps if it doesn't indicate that it does work, then there is a bug in the FAQ page you listed.)
If you are looking to see the SQL data, the SQLIDEBUG part of the FAQ works:
That generated a file distsel_6004_0_102d40 for me - it will be different for you. You can then use the 'sqliprint' utility to see the data flowing between client and server.
If you cannot find 'sqliprint', get back to me.