Attempting to supply an explicit value to a generated (virtual or stored) column triggers this MySQL 3105 error.
MySQL error 3105 ER_NON_DEFAULT_VALUE_FOR_GENERATED_COLUMN occurs when an INSERT or UPDATE tries to assign a value to a generated column. Remove the explicit column value or use INSERT ... DEFAULT to fix the issue.
ER_NON_DEFAULT_VALUE_FOR_GENERATED_COLUMN
MySQL raises error code 3105 with the condition name ER_NON_DEFAULT_VALUE_FOR_GENERATED_COLUMN when a statement supplies a non-default value to a generated column. Generated columns compute their content from an expression and should not be directly written by the user.
The error appears from version 5.7.6 onward, affecting both virtual and stored generated columns during INSERT, REPLACE, UPDATE, bulk load, or replication events.
Ignoring the rule breaks data integrity because generated columns must always mirror their defining expression. Allowing manual values could corrupt downstream logic, indexes, or constraints that rely on the computed data.
Supplying explicit column values in INSERT or UPDATE statements is the primary trigger. The error can also surface when a client library or ORM accidentally lists all columns including generated ones.
Another cause is attempting to copy data with SELECT ... INTO or LOAD DATA that includes the generated column in the column list.
Rewrite the statement so the generated column is omitted, or explicitly request its default value. MySQL will then calculate the column automatically.
If an ORM generates the SQL, configure it to exclude generated columns from write operations. Verify model metadata so only base columns are updatable.
During table migration, scripts may use INSERT INTO new_table SELECT * FROM old_table. Replace the asterisk with an explicit column list that skips generated columns.
In bulk imports, use LOAD DATA ... (col1,col2,...) excluding the generated column, or map the position to @dummy to ignore it.
Always name columns explicitly in INSERT and UPDATE statements instead of relying on SELECT *. This prevents accidental writes to generated columns when the schema evolves.
Keep generated column definitions in documentation and tag them clearly in Galaxy Collections so teammates recognize they should never be written directly.
Error 1575 ER_GENERATED_COLUMN_FUNCTION_IS_NOT_ALLOWED happens when an unsupported function is used in the generated column expression. Revise the expression to comply with allowed functions.
Error 3106 ER_WRONG_FK_OPTION_FOR_GENERATED_COLUMN occurs if a generated column is referenced incorrectly in a foreign key. Drop or change the constraint to use a base column.
Writing INSERT INTO t(col1,generated_col) VALUES(...)
Running UPDATE t SET generated_col=5 WHERE id=1
Frameworks that use INSERT ... VALUES(default, ...) for every column mistakenly supply a value for generated_col
LOAD DATA INFILE that sends all CSV fields into all table columns
Raised when a generated column is referenced in a foreign key with unsupported options.
Occurs when the expression for a generated column uses a disallowed function.
Triggered by unsupported options such as UNIQUE on virtual generated columns prior to 8.0.13.
No. Generated columns are always computed by MySQL. Use DEFAULT if you must list the column.
Yes. MySQL blocks manual values for either type.
Query INFORMATION_SCHEMA.COLUMNS where EXTRA='VIRTUAL GENERATED' or 'STORED GENERATED'.
No. The check is independent of sql_mode. MySQL will still enforce it.
.avif)
.avif){kind=logo}
