<p>MySQL raises error 1362 when a BEFORE or AFTER trigger tries to modify the same row currently being processed, preventing infinite recursion and inconsistent data changes.</p>
<p>MySQL Error 1362: ER_TRG_CANT_CHANGE_ROW occurs when a trigger updates, deletes, or inserts the very row that fired it. Stop the self-reference, move logic to a stored procedure, or use a different table to fix the problem.</p>
Updating of %s row is not allowed in %strigger
Error 1362 appears with the message Updating of %s row is not allowed in %strigger. MySQL blocks any attempt by a trigger to change the same row that invoked it, because doing so could create endless loops or mismatched data.
The error is specific to triggers defined with BEFORE or AFTER timing. It surfaces immediately when the offending statement is parsed, so the affected rows are never modified.
The main cause is issuing an UPDATE, DELETE, or INSERT on the base table inside its own trigger. MySQL detects the circular modification and halts execution with error 1362.
The error also appears when a trigger indirectly calls a stored routine that touches the same table. Even nested procedure calls are checked by the server.
Rewrite the trigger so it does not modify the originating table. Move the business logic to a separate stored procedure that you call from the application layer instead of from the trigger.
In some designs you can create an auxiliary table for intermediate storage, then use a scheduled job to sync changes back, eliminating the self-reference.
Auditing triggers often try to UPDATE a last_modified column in the same row. Replace that with a BEFORE UPDATE trigger that sets NEW.last_modified, avoiding an explicit UPDATE statement.
Cascading updates between parent and child tables can also cause the error if both tables share the same trigger. Make sure only one side performs the change or use foreign keys with ON UPDATE CASCADE instead of manual triggers.
Keep triggers simple and read-only whenever possible. Perform only validation, default setting, or logging. Delegate complex updates to application code or scheduled jobs.
Review triggers after every schema change. Automated tests that insert, update, and delete sample data will quickly reveal recursion issues before they reach production.
Error 1442 HY000 arises for the same circular update pattern inside stored functions. The fix strategy is identical: remove the self-referencing modification.
Error 1364 HY000 occurs when a field in a trigger is assigned NULL but declared NOT NULL. Ensure default values or explicit assignments satisfy column constraints.
The trigger body runs UPDATE, INSERT, or DELETE on the same table that fired it, causing an immediate 1362 error.
A procedure called from the trigger changes the table, and MySQL still flags the circular dependency.
Nested triggers on parent and child tables end up touching the same row twice during a single statement.
Audit triggers attempt to stamp timestamps by issuing a separate UPDATE rather than assigning NEW.column.
Raised when a stored function tries to modify the table that invoked it. Remove the self-update or move logic elsewhere.
Occurs in triggers when NEW.column is left NULL for a NOT NULL field. Provide a value or default.
Happens outside triggers when a subquery reads from and writes to the same table. Use a derived table or temporary table.
Yes, but only by assigning values to NEW or OLD in a BEFORE trigger. Running a separate UPDATE, INSERT, or DELETE statement on the same table is blocked.
Both timings are restricted. Any explicit modification to the base table inside the trigger body results in error 1362.
No. The restriction is hard coded in the server to prevent recursion. Configuration flags cannot override it.
Galaxy's AI copilot flags self-referencing updates during query review and suggests safer patterns, helping you catch the issue before deploying the trigger.
.avif)
.avif){kind=logo}
