To be pedantic, DBI tracing will show you only what was passed to the database, not what was actually executed.
Missing manuals should be no problem for most databases. Those of SQLite, PostgreSQL and MySQL are freely available and complete on the WWW. For MS SQL Server, Oracle, and DB2, you will also find most of the documentation on the WWW, either at Microsoft/Oracle/IBM, or at some website that ignores the copyright on those documents. In all cases, Google should be able to find the documentation.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
To be pedantic, "no, it won't", but I understand what you say. DBI tracing might show only what DBI executes, but depending on the DBD, it might also show you exactly what teh database is doing. There are just a few guidelines for debug support in DBD's, and while we are very slowly trying to get those in line, the way the DBD interprets the trace settings is still very depending on how the author of the DBD thinks that is done best.
In DBD::Unify I started to support the dbd_verbose attribute a long long time ago, and it is now also supported in DBD::Oracle and DBD::Pg and perhaps in others too by now.
The advantage of using dbd_verbose is that you by now probably trust that DBI does what it is supposed to do (bug-free). Most of the time, the problems encountered are not in the DBI interface, but on the DBD side, and dbd_verbose will control what the DBD is printing as debug information while DBI will completely ignore it.
It however still holds that depending on the DBD, this information might be differing from what the database engine/server actually executes, but at least you're getting information that is closer to the truth than what the top level knows about.
Hope this helps a bit ...
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |