Technically speaking, everyone may have attacked this wrong. Remember that the DBI puts the last error produced into $DBI::errstr aka $dbh->errstr. Most likely, at the DBI->connect jettero has RaiseError => 1 which is going to be the real culprit.

I preach using RaiseError until the code goes to production. Why? Because I don't want my scripts to produce any output until it is clean. Thus, the result will oft be located in the apache error-log.

jettero doesn't want this to happen, so first he should set RaiseError => 0. (Btw, I don't use PrintError since RaiseError does the same with a warn.) Now, after each DBI prepare and do, a good little coder will test for success, and finding there is none means it's time to put the $DBI::errstr into whatever container you're using to hold all errors. (This is only valid if a single error is not going to kill the rest of the script) Then, lo you may print the container of errors to STDOUT along with everything else.

While jettero's answer does handle properly, it's also what signalled that he is using RaiseError. I'm advocating this method since some errors may need to be handled differently (ie - stop execution of the script) than others. His own answer to his question is probably valid in the sense that he may not have this requirement.

ALL HAIL BRAK!!!