$dbInsert=$db->prepare($insertCom)
  or die join(" : ", "DBI prepare failed!",$db->err, $db->errstr);
[download]

You can use $DBI::err and $DBI::errstr if you want something you can interpolate.

Once again, I prefer RaiseError in most circumstances. In most cases, there is nothing that the program can do about a fatal DB error. It usually makes the most sense to just stop. The OP showed very little of his code and even less explanation. It should be noted that "prepare" can be an "expensive" operation and, therefore most code attempts to prepare a statement once and use that statement many times.

Perhaps it could be that whatever is driving the generation of multiple identical tables with different names, this can be simplified to a single table table with one extra column to represent that factor. That way you could have a single prepared statement that works with what were before multiple tables and now is a single table? The table name cannot be a variable in a prepared statement.

Unfortunately, not even that will work seeing as how $sth hasn't even been declared.

So the code below gave me the most detail. I tried checking for $dbHandle->err after the prepare statement but it returned nothing.

And I just wanted to just be clear: setting RaiseError => 1 does cause the script to exit immediately, yes?

Thanks for everyone's help.

sub insertItem {
    (my $insertCom) = @_;
    
    $dbHandle=$db->prepare($insertCom);


    my $result = $dbHandle->execute();
    if ($dbHandle->err || $dbHandle->errstr) {
        $logger->debug("err | $DBI::err | $DBI::errstr");
    }
    


    return $result;
}
[download]

setting RaiseError => 1 does cause the script to exit immediately, yes?

yes, unless the "offending" code is wrapped in an →eval (what ForgotPasswordAgain suggested in Re^3: Can I get the actual error for DBI->execute() ?) or some form of →Try Catch Exception Handling. If your Perl is too old for the latter (or other reasons), there are Try::Tiny and friends.

SergioQ wrote: And I just wanted to just be clear: setting RaiseError => 1 does cause the script to exit immediately, yes?

Yes. You can also log any errors associated with the database handle without exiting by passing PrintError => 1 and warnings with PrintWarn => 1 to the DBI->connect() call. I generally don't want to make any changes to the database if any errors occur so I use AutoCommit => 0, and only $dbh->commit if everything passes within whatever constraints I set.

Yes. setting RaiseError => 1 does cause the script to exit immediately, yes?

I prefer to do it that way instead of checking for errors after each DB operation. In your code above, prepare can also throw an error. $dbHandle will be undef if there is an error and you should check for that if you don't set RaiseError.

Note that execute sometimes returns a numerical value that has meaning, like perhaps the number of rows updated. execute behaves differently say for a SELECT statement where no information is provided. So a simple check of $result to detect an error won't work like it does for $dbHandle.