The server raises ER_TABLE_NOT_LOCKED_FOR_WRITE when a write statement targets a table that was only READ locked in the current session.
MySQL Error 1099: ER_TABLE_NOT_LOCKED_FOR_WRITE means the table is locked for READ only, so INSERT, UPDATE, or DELETE cannot run. Issue UNLOCK TABLES or lock the table with WRITE before executing the statement to resolve the problem.
Table '%s' was locked with a READ lock and can't be
Error 1099 appears with the message: "Table '%s' was locked with a READ lock and can't be updated." The server blocks any INSERT, UPDATE, DELETE, or REPLACE that targets a table currently locked for READ by the same session.
The error is connection specific. One thread can hold a READ lock, attempt a write, and receive 1099 even while other connections hold no lock at all.
It surfaces under LOCK TABLES statements, explicit or generated by some backup utilities.
A session issues LOCK TABLES ... READ and then tries to modify the same table without upgrading to WRITE. MySQL enforces consistency by refusing the change.
Using mysqldump --lock-tables keeps tables READ locked during the dump.
Accidentally running update scripts in the same connection triggers the error.
Stored procedures or triggers that call a write statement while the caller holds only READ locks also produce 1099.
Release the READ lock before modifying data.
Execute UNLOCK TABLES or end the transaction to remove all locks.
If you still need a lock, re-lock the table with WRITE or WRITE LOCAL, then run the modification.
When using mysqldump, add the --single-transaction flag instead of --lock-tables so backups run without long READ locks.
Dump plus patch - A developer dumps a table with LOCK TABLES, edits data, and gets 1099.
Solution: run UNLOCK TABLES before the patch.
Long-running report - Analytics code locks a table READ, loops for analysis, then tries an UPDATE. Fix: split read and write phases into separate connections.
Trigger recursion - A trigger fires and writes back to the same table locked READ. Solution: acquire WRITE lock or redesign trigger logic.
Always match lock intent with operation type.
Use WRITE locks for sessions that may modify data.
Favor transaction isolation (START TRANSACTION) with SELECT ... FOR UPDATE instead of explicit LOCK TABLES when possible.
In Galaxy's SQL editor, run read-only exports in one tab and perform data fixes in another to ensure separate lock scopes.
Error 1100 (ER_TABLE_NOT_LOCKED) - Happens when a table needs any lock but isn’t locked at all.
Lock the table appropriately.
Error 1205 (Lock wait timeout) - A thread waits too long for a lock. Reduce contention or increase innodb_lock_wait_timeout.
Error 1213 (Deadlock found) - Circular lock dependency detected. Re-order statements or use smaller transactions.
.
The connection explicitly executed LOCK TABLES table_name READ and then tried to perform a write.
Backup utilities lock tables in READ mode during export; if a post-dump script runs in the same session, writes fail.
Server-side code that writes to a table while the caller holds only a READ lock causes the error.
Applications combining analytical SELECTs with subsequent updates under the same READ lock encounter 1099.
.
Your script likely issues LOCK TABLES READ before writing. The interactive client uses implicit locks, so the problem is hidden there.
No. Ignoring it means your write never executed. Always fix the lock state instead.
UNLOCK TABLES releases explicit table locks, while COMMIT ends a transaction. They are separate commands and may both be required.
Galaxy lets you run read-only queries in isolated tabs, reducing chances of mixing READ locks with write operations in the same session.
.avif)
.avif){kind=logo}
