<p>MySQL error 1697 arises when a PARTITION VALUES clause contains a non-integer value although the partitioning column is defined as INT.</p>
<p>MySQL Error 1697: ER_VALUES_IS_NOT_INT_TYPE_ERROR appears when a VALUES list for a RANGE or LIST partition contains something other than an INT. Convert the literal or column to INT, recreate the partition definition, and the statement will succeed.</p>
VALUES value for partition '%s' must have type INT
Error 1697 is triggered during CREATE TABLE or ALTER TABLE when MySQL validates partition definitions. The VALUES list for each partition must match the data type of the partitioned column. If the column is INT but the VALUES entry is not an integer, MySQL raises ER_VALUES_IS_NOT_INT_TYPE_ERROR with the message "VALUES value for partition '%s' must have type INT".
MySQL enforces strict type checking for RANGE and LIST partitions to guarantee deterministic partition pruning. A character literal, decimal constant, or function call in a VALUES list cannot be implicitly cast to INT in this context, so the parser aborts with error 1697.
Confirm the partitioning key data type, rewrite each VALUES clause to use integer literals, and re-execute the DDL. When the source data is VARCHAR or DECIMAL, cast or convert it before inserting or choose a compatible INT column for partitioning.
The error surfaces after schema migrations, automated code generation, or manual edits that introduce string dates (e.g. '20240101') or numeric values with quotes into VALUES lists. CI pipelines that run DDL scripts also frequently surface the problem.
Writing VALUES ('100', '200') instead of 100, 200 makes MySQL treat them as strings, causing the mismatch.
Including 100.0 or 50.5 in a VALUES list for an INT column triggers the error because decimals are not integers.
Using UNIX_TIMESTAMP() or other functions inside VALUES prevents MySQL from validating an INT at parse time.
Occurs when the partition function uses an unsupported expression such as RAND().
Raised when the column list in a partition definition does not match the primary key.
Appears when you attempt to partition by a column type that MySQL does not allow, such as TEXT or BLOB.
No. MySQL enforces this rule at parse time to preserve partition integrity.
No. MySQL requires literal integers. CAST() and functions are evaluated at runtime, not at DDL parsing.
The rule exists in all GA versions that support partitioning. From 5.1 to 8.1 the behavior is identical.
Galaxy's type-aware linting flags non-integer VALUES in real time and the AI copilot auto-corrects them before you run the statement.
.avif)
.avif){kind=logo}
