MySQL Error 1134 (ER_UPDATE_INFO) is an informational notice that reports how many rows were matched, changed, and warned after an UPDATE but may be surfaced as an error by some clients or drivers.
MySQL Error 1134: ER_UPDATE_INFO appears when the server returns the Rows matched/Changed/Warnings statistics after an UPDATE and the client treats the notice as an error. Treat it as a warning or adjust client settings to resolve the issue.
Rows matched: %ld Changed: %ld Warnings: %ld
MySQL sends the message “Rows matched: %ld Changed: %ld Warnings: %ld” after every UPDATE statement to summarize its outcome. Internally this is tagged ER_UPDATE_INFO with error code 1134 and SQLSTATE HY000.
Most MySQL shells display the string as an informational notice.
Certain connectors, ORMs, or logging layers misinterpret the packet as an error and raise an exception, disrupting application flow.
Clients that default to treating any non-zero error code or SQLSTATE HY000 as an exception will surface ER_UPDATE_INFO even though the statement completed successfully.
Old MySQL client libraries (pre-5.6) and some thin JDBC/ODBC wrappers lack differentiation between notices, warnings, and errors, leading to false-positive error handling.
First, confirm that the UPDATE ran by checking the affected row counts in MySQL or the Galaxy query history.
If data changed correctly, adjust the client configuration so ER_UPDATE_INFO is handled as a warning.
Many drivers expose flags such as CLIENT_FOUND_ROWS, suppressInfoMessages=true, or log-only notice levels. Enable these to prevent exceptions while still logging the row statistics.
Web applications using Python mysqlclient 1.3.x often see OperationalError: 1134. Upgrade to mysqlclient 2.x or wrap the call in try/except that ignores 1134.
Java apps on MySQL Connector/J before 8.0.29 may throw SQLNonTransientException.
Set dumpQueriesOnException=false and enablePacketDebug=false, or upgrade the connector.
Always use the latest MySQL connectors, which classify ER_UPDATE_INFO correctly. Pin versions in dependency manifests to avoid regression.
In Galaxy, enable query result metadata preview so developers see the matched/changed counts directly, preventing confusion and needless exception handling.
ER_INSERT_INFO (code 1135) reports row counts for INSERT statements and can trigger the same client misclassification.
Treat it identically.
Warnings such as Rows matched but not changed (SQLSTATE 01000) may also be surfaced as errors. Adjust warning filters rather than catching generic exceptions.
.
No. It is an informational notice that some clients misinterpret. The UPDATE has already succeeded.
Not directly. The server always sends the packet. Suppress or reclassify it on the client side.
No. The transaction state is unaffected. You can still COMMIT or ROLLBACK normally.
Galaxy’s editor surfaces the matched/changed counts inline and classifies ER_UPDATE_INFO correctly, preventing false alarms during collaboration.
.avif)
.avif){kind=logo}
