asked on
WHY IS MYSQL REJECTING ASCII CHARACTER INSERTION INTO CHAR TYPE COLUMN
I'm getting a rejection error when installing a new record into mysql (from vfp). I suspect it might be mysql being somewhat stricter about data types that vfp.
The data in question is an SHA256 hash value in plain ascii (32 chrs) which I can insert into a VFP table till the cows come home.
Mysql rejects it with the following message - which I do not understand:
[MySQL][ODBC 8.0(w) Driver][mysqld-8.0.19]Inco
That looks like a clunky way to express the hex values of the ascii string but that doesn't make sense because the hex version of the string is 0hBEEC0F153832825A8647806E
The initial data type I had set the mysql column to was Varchar (32)
after reading refs in the mysql tooltip text re Varchars, which refers to utf8 chars requiring up to 3 bytes per char, I switched to plain CHAR which reported no such strictures, but I get the same error with that.
To test my hypothesis that it was somehow related to data type, instead of creating an ascii string, I created the hashes in hex and just used the first 32 characters of the 64 byte hex string. That worked a treat. Of course that's no use in the real world and I have no intention of switching to 64 byte fields just so I can use the full hex string because one of my requirements is to keep the whole table as lean as possible and 32 chrs is as lean as we can get with 256 bit hash. So it looks as though the ascii strings are being rejected because they contain one or more non standard characters.
Is that down to an encoding parameter I haven't applied or am I barking up completely the wrong tree?
The data in question is an SHA256 hash value in plain ascii (32 chrs) which I can insert into a VFP table till the cows come home.
Mysql rejects it with the following message - which I do not understand:
[MySQL][ODBC 8.0(w) Driver][mysqld-8.0.19]Inco
That looks like a clunky way to express the hex values of the ascii string but that doesn't make sense because the hex version of the string is 0hBEEC0F153832825A8647806E
The initial data type I had set the mysql column to was Varchar (32)
after reading refs in the mysql tooltip text re Varchars, which refers to utf8 chars requiring up to 3 bytes per char, I switched to plain CHAR which reported no such strictures, but I get the same error with that.
To test my hypothesis that it was somehow related to data type, instead of creating an ascii string, I created the hashes in hex and just used the first 32 characters of the 64 byte hex string. That worked a treat. Of course that's no use in the real world and I have no intention of switching to 64 byte fields just so I can use the full hex string because one of my requirements is to keep the whole table as lean as possible and 32 chrs is as lean as we can get with 256 bit hash. So it looks as though the ascii strings are being rejected because they contain one or more non standard characters.
Is that down to an encoding parameter I haven't applied or am I barking up completely the wrong tree?
MySQL Server
Last Comment
Mike Jacobs