debugsqlMinor
SQL Error [1292] "Truncated incorrect INTEGER value" - with Varchar columns and CASE. Why?
Viewed 0 times
casewhyerrorincorrectcolumnssqlwithvarcharvalue1292
Problem
In a MySQL 5.7 environment, when trying to insert a varchar value into a varchar field, I get the error:
SQL Error [1292] [22001]: Data truncation: Truncated incorrect INTEGER value: '1876301/347'
The source and target columns are both of the datatype
Here's a small demo to reproduce an example of the error (it occurs on the last insert):
To generate the error, now run this: (is the 3rd
It seems to be related to there being a case statement, as, when I try to simply insert the same value directly, it works fine.
It also works fine with the
SQL Error [1292] [22001]: Data truncation: Truncated incorrect INTEGER value: '1876301/347'
The source and target columns are both of the datatype
varchar.Here's a small demo to reproduce an example of the error (it occurs on the last insert):
create table SRC
(
Z varchar(20) null,
A varchar(63) null,
B varchar(30) null
);
insert into SRC
select 'XYZ', '1876301/347', null
;
create table TGT
(
C varchar(63) null
)
;To generate the error, now run this: (is the 3rd
WHEN that matches, meaning it's trying to insert the value from SRC.A into TGT.C)insert into TGT
(
C
)
select
CASE
WHEN if(Z in ('XYZ'), A, NULL) IS NULL AND B IS NULL THEN NULL
WHEN if(Z in ('XYZ'), A, NULL) IS NULL AND B IS NOT NULL THEN B
WHEN if(Z in ('XYZ'), A, NULL) IS NOT NULL AND B IS NULL THEN A
WHEN if(Z in ('XYZ'), A, NULL) IS NOT NULL AND if(Z in ('XYZ'), A, NULL) = B THEN A
ELSE if(Z in ('XYZ'), A, NULL)
END AS C
from
SRCIt seems to be related to there being a case statement, as, when I try to simply insert the same value directly, it works fine.
insert into TGT
(
C
)
select
A
from
SRCIt also works fine with the
CASE STATEMENT if I use INSERT IGNORE INTO..., but I'd rather not use that.Solution
I received this message doing an insert. The select worked fine but when prefixed with "insert into blablabla" it hated my guts. The problem turned out the be the character set of the target varchar. My dev environ defaulted to "latin" when creating a new varchar for a new table, but the varchar in the source table was "utf8" with a "utf8_unicode_ci" collation. When I corrected that in the new destination table, MySQL and I were on much better terms.
Context
StackExchange Database Administrators Q#284040, answer score: 3
Revisions (0)
No revisions yet.