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.
In reply to Re^3: Can I get the actual error for DBI->execute() ?
by Marshall
in thread Can I get the actual error for DBI->execute() ?
by SergioQ
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |