Re: Not solved - mysql data truncation does not cause an error to be thrown

From: Date: Fri, 09 Nov 2007 11:12:42 +0000
Subject: Re: Not solved - mysql data truncation does not cause an error to be thrown
References: 1 2 3 4  Groups: php.db 
Request: Send a blank email to php-db+get-44327@lists.php.net to get a copy of this message
Hiya This seems to be one thing java has over php (perl etc) as it does know about the warning and acts approperately. This should be an option to ignore or not ignore warnings within php to prevent errorless truncation of data. Cheers Andy chris smith wrote:
On Nov 9, 2007 8:34 PM, Andrew Blake <a.blake@har.mrc.ac.uk> wrote:
Hello It seems that the normal mysql_query doesn't error when an sql command forces the server to truncate the data. The mysql server executes the sql and provides a warning but it still executes the sql so allowing php to ignore the fact that there is a warning. You can run another sql command "SHOW COUNT(*) WARNINGS" after your insert command to check if there is a warning and roll back the changes - similar to the java mysql interface. I haven't used mysqli and perhaps this is addressed in that ?
    
I doubt it.
Using sqlyog (3rd party mysql gui) to run the sql also provides no warning message but running it on the command line provides the "1 row affected, 1 warning message" With data validation and check this data too large situation should never happen but surely php should pay attention to the warnings too ?
    
It's not a php problem. Mysql should throw proper errors instead of a 'warning'. http://dev.mysql.com/doc/refman/4.1/en/blob.html If you assign a value to a BLOB or TEXT column that exceeds the data type's maximum length, the value is truncated to fit and a warning is generated. Same for char/varchar & binary fields (http://dev.mysql.com/doc/refman/4.1/en/binary-varbinary.html and http://dev.mysql.com/doc/refman/4.1/en/char.html). You will get the same "problem" in other languages I'm sure (try it in python, perl, ruby).


« previous php.db (#44327) next »