While reviewing the log files for a project I am working on I came across a MySQL error that dealt with mismatched character sets. Specifically the table was set to latin1 and the connection was set to UTF8. This error was rare but happened at the right time for me to catch it, as I was reviewing the log files for an unrelated problem.
Further investigation revealed that the schema and some tables were set to latin1. If we weren’t setting the connection to UTF8 this wouldn’t be a problem. So I set to work on creating a database update to include the alter database and necessary alter table statements.
The first statement among the list of statements that needs to run:
ALTER DATABASE project CHARACTER SET UTF8.
Response from MySQL: Error 1192: “Can’t execute the given command because you have active locked tables or an active transaction”
I was stuck, as this had run fine in the development, QA, and staging environments. Why would it fail in production? The tables didn’t have any locks, and there were no transactions that I was aware of. My Google-Fu led me to the MySQL 5.1 Reference section 13.3.3. Statements That Cause an Implicit Commit. Armed with the knowledge that create, alter, delete table statements cause implicit commits, I was still stuck where I began.
I began reviewing our database update mechanism (based on Zend Framework Database Table Adapters) and found that it was starting a transaction before running the statements. I set forth to update the tool, but some updates needed transactions for their modifications, so I ended up running the query manually.
Sometimes there is no easy answer and you need to just Ops up and get your DBA on.