<p>The error appears when LOAD DATA tries to read a fixed-length file into a table that has variable-length columns or incompatible field/line definitions.</p>
<p>MySQL Error 1409: ER_LOAD_FROM_FIXED_SIZE_ROWS_TO_VAR occurs when LOAD DATA attempts to import a fixed-size row file into a table with variable-length columns. Align column types with file widths or switch to delimited format to resolve the issue.</p>
Can't load value from file with fixed size rows to
Error 1409 is raised by the MySQL storage engine when the LOAD DATA [LOCAL] INFILE command tries to read a flat file that stores rows in a fixed byte length, but the target table contains one or more variable-length columns such as VARCHAR, TEXT or BLOB.
Because MySQL cannot determine where each field ends in a fixed-width record when the table expects variable-width storage, it aborts the load and returns the message "Can't load value from file with fixed size rows to variable".
The import stops at the first offending row, leaving the table partially loaded or completely empty. In ETL pipelines this can break downstream jobs, delay reporting and cause data loss if not detected quickly.
You will see it after executing a LOAD DATA command with the FIELDS TERMINATED BY '' option (empty string) or when using FIXED format files generated by legacy systems, COBOL copybooks or mainframe exports.
The main trigger is a mismatch between the file's fixed byte layout and the table's variable-length definitions. MySQL expects every column to map to a known byte width when FIELDS TERMINATED BY '' is specified.
Choose one of three strategies: 1) change the table to CHAR or BINARY columns with exact widths; 2) switch the file to a delimited format and specify proper FIELDS TERMINATED BY and LINES TERMINATED BY clauses; 3) load into a staging table of fixed columns, then INSERT...SELECT into the final table.
Legacy EBCDIC extracts, mainframe report files and C programs often write fixed 100-byte records. If your target table uses VARCHAR, convert those columns to CHAR( n ) temporarily or load into a CHAR staging table first.
Standardize inbound files to CSV or TSV; validate file width against table metadata in CI pipelines; document field sizes in Galaxy Collections so all engineers load data consistently.
The input file stores 20-byte customer names but the table column is VARCHAR(50), triggering the mismatch.
An empty string indicates fixed-width parsing, but the table still contains variable types.
The file omits padding spaces that MySQL expects when mapping to CHAR fields.
Occurs when imported value exceeds column width.
Raised during LOAD DATA when date strings do not match column format.
Appears if FIELDS TERMINATED BY is malformed.
Yes. Load into a staging table of CHAR columns first, then cast to VARCHAR in an INSERT...SELECT.
No. LOCAL only changes file location semantics. The fixed-width versus variable-length mismatch still applies.
sql_mode does not influence this error. Column type compatibility is mandatory.
Galaxy highlights table schemas inline and stores endorsed LOAD statements, reducing accidental format mismatches during data onboarding.
.avif)
.avif){kind=logo}
