In the general case, it's irrelevant, for several reasons:

• There's no requirement that the database sees a query with the statement and values integrated, and hence, no requirement for DBI to construct one. When a database supports precompilation and column binding, then the DBI placeholder is a good model of what's going on.
• There's no requirement that DBI is even talking to an SQL database! It can be fronting for something else entirely.

Since you can track the SQL you give to prepare and have access to the arguments you pass the execute function, I'd suggest just logging that in the event of an error. You could even replace the values yourself. Something like the naive:

$ST=$DB->prepare($SQL);
if (! $ST->execute(@args)) {
    $SQL=~s/\?/$_/ for @args;
    print "STATEMENT: $SQL\nERROR: $DBI::errstr\n\n";
}
[download]

could be enough to do the trick. (Yes, it's buggy: for the same reasons that you don't just composite the SQL command and data values and execute it that way. But for debugging purposes, it should do just fine.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.