views:

133

answers:

3

I'm working with a third-party application that uses ODBC to connect to, and alter, a database. During certain failure modes, the end-results are not what I expect. To understand it better, I'd like some way of inspecting all the statements sent to the database. Is there a way to do this with ODBC?

I know with JDBC I could use http://www.p6spy.com/ to see all statements sent, for example when debugging hibernate. p6spy is a "proxy" driver that records commands sent and forwards them on to the real JDBC driver.

Another possibility might be a protocol sniffer that would capture statements over the wire. Although, I'm unsure if ODBC includes a standard wire protocol, or only specifieds the API.

Does anyone know of existing tools that would allow me to do either of these things? Alternatively, is there another approach I could take?

A: 

I think it is easier to read the logs on the SQL side, whatever the database. For example, turning on the monitor on SQL Server or viewing the logs in MySQL. It seems that using a sniffer would be more trouble than it is worth, but I guess it depends on the tools available. What RDBMS are you using?

MJB
We are using DB2. I'm only interested in traffic originating from one machine at a time. They are also generally segregated by the schema they edit, so it might be possible to use the logs from a single schema.
Dave Cameron
Well, I have used DB2 as a programmer, but never a DBA, so I can't say anything specific about the logs. But that sounds like a decent place to look.
MJB
+1  A: 

ODBC specifies how your program communicates with a local driver, not how the local driver communicates with the remote database. Your proxy driver idea is sound, you just need to find one.

Matthew Flaschen
+1  A: 

Have you tried the tracing built into ODBC? In ODBC Data Source Administrator, there is a tracing tab. As I remember, the information captured is pretty verbose.

Shannon Severance