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.

thanks - it is just for debugging to write the statements in a log. I know i have access to all of the information but i was hoping i could get the sql from the dbi rather than preparing it myself.

You pass the SQL as the first argument to $dbh-do - no need to extract it from the error message.

Please also read What shortcuts can I use for linking to other information?

Until I read the answer from roboticus I didn't even think you might have thought a driver replaced the placeholders with your parameters in the SQL string. The purpose of preparing a statement with parameters is that the database can parse the SQL once, may be compile it, build an execution plan, optimise it, cache it etc as in most cases the parameters won't affect this. Drivers generally pass the SQL string including placeholders to the database engine then pass the parameters separately afterwards. So long as you are using prepare/execute (and not do) you can access the SQL you passed to prepare with the Statement attribute and the parameters via the ParamValues, ParamTypes and ParamArrays.