Data too long for column

Version imprimable

Bonjour,

j'ai un soucis avec une requête SQL
Voilà la structure de ma table :

Citation:

CREATE TABLE `forme_compo` (
`ID_LibFCompo` smallint(4) unsigned NOT NULL auto_increment,
`ID_FCompo` smallint(4) unsigned NOT NULL,
`Lib` varchar(255) NOT NULL,
`Code_FCompo` char(5) NOT NULL default 'zz',
`Comment_FCompo` text NOT NULL,
`Code_Langue` char(3) NOT NULL default 'fre',
PRIMARY KEY (`ID_LibFCompo`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Forme musicale de l''oeuvre pour la musique et les partitions' AUTO_INCREMENT=3 ;

Je fais l'insertion d'une ligne avec phpmyadmin qui me retourne cette requête et cette erreur.
Code:

1 2 3 4 5 6 INSERT INTO `forme_compo` ( `ID_LibFCompo` , `ID_FCompo` , `Lib` , `Code_FCompo` , `Comment_FCompo` , `Code_Langue` ) VALUES ( NULL , '156', 'Cotillon', 'ctl', 'A utiliser aussi pour \'contredanse française\'', 'fre' ) MySQL a répondu:Documentation #1406 - Data too long for column 'Comment_FCompo' at row 1
Pouvez-vous m'aider, je ne comprend pas du tout ce qu'il ce passe !!!!

Merci d'avance

31/10/2007, 16h12
Jasmine80

Je viens de créer la table et d'y insérer les données en faisant des copier-coller de tes 2 requêtes et chez moi cela fonctionne très bien. C'est étrange, j'utilise EasyPHP 1.8 et toi?

Jasmine,

essaie avec

Code:

1
2
3
4
INSERT INTO `forme_compo` ( `ID_LibFCompo` , `ID_FCompo` , `Lib` , `Code_FCompo` , `Comment_FCompo` , `Code_Langue` )
VALUES (
NULL , '158', 'Cotillon', 'ctl', 'A utiliser aussi pour ''contredanse française''', 'fre'
) ;

31/10/2007, 18h40
epeichette

Merci de vos réponse,

J'ai mysql 5 et quand je passe la requête en ligne de commande c'est pareil. Après plusieurs test il me semble que c'est le "ç" qu'il n'aime pas ce que je ne comprend pas du tout.
J'ai essayé de recréer la table dans un autre base de ce serveur et c'est pareil. Par contre si je fais le test avec le même table créer mais sur un autre serveur mysql 4 l'enregistrement ce fait normalement.

J'ai regarder dans mon fichier my.ini et le langage par défaut est le latin dans les 2 je ne comprends pas du tout ce qui pourrait empêcher l'enregistrement d'un "ç" ou de caractère avec accent.
Merci de votre aide

La question est de savoir quel est le jeu de caractères de ton client :

Code:

Select @@character_set_client ;

Si par exemple tu es en UTF8, teste ta requête ainsi :
Code:

1 2 3 4 INSERT INTO `forme_compo` ( `ID_LibFCompo` , `ID_FCompo` , `Lib` , `Code_FCompo` , `Comment_FCompo` , `Code_Langue` ) VALUES ( NULL , '158', 'Cotillon', 'ctl', _utf8'A utiliser aussi pour ''contredanse française''', 'fre' ) ;

02/11/2007, 09h20
epeichette

ok alors contre toute attente, la réponse à

Code:

SELECT @@character_set_client ;

est utf_8. Je ne comprend pas pouquoi dans la mesure où dans my.ini j'ai latin1 de déclarer et que ma base comme l'ensemble de mes tables sont déclarés en "latin1_swedish_ci"

D'où vient cet utf8 et surtout comment faire pour le passer en Latin 1?

Sinon, j'ai passé la requête indiquée et j'ai toujours le même message d'erreur 8O

bonjour,

il y a un truc que je ne comprends pas dans ta requête :?
tu déclare ton champs:

Citation:

ID_LibFCompo` smallint(4) unsigned NOT NULL auto_increment

et tu lui passes NULL comme valeur 8O
Si ton champs est en auto_increment, tu n'as pas a lui passer de valeur, il va la prendre tout seul :roll:
Ca peu peut être, être la cause de ton problème. Mysql qui se mélange les pinceaux au niveau des colonnes. Essaie ca:
Code:

1 2 3 4 5 6 7 INSERT INTO `forme_compo` ( `ID_FCompo` , `Lib` , `Code_FCompo` , `Comment_FCompo` , `Code_Langue` ) VALUES ( '158', 'Cotillon', 'ctl', 'A utiliser aussi pour ''contredanse française''', 'fre' ) ;

03/11/2007, 10h43
epeichette

Non que l'on passe ou non la valeur de l'id en null ne change rien...:(
Après de multiple test, ce sont bien les caractères comme le ç ou ù ou à qui pose problème.

Donc comme le suggérait Antoun, ce serait bien un problème de définition des caractères qui pose soucis.
Maintenant comme il me semble avoir tout déclarer en latin1, je ne vois pas d'où vient le utf8 qui m'est retourner avec

Code:

SELECT @@character_set_client ;

En plus j'ai le même retour avec mon serveur mysql 4 dans lequel la requête passe sans problème. Il n'y a qu'avec mysql 5 que ça ne passe pas.

Qu'est qui fait que cela passe avec mysql 4 et pas mysql 5. Certainement un élément de configuration mais lequel????
03/11/2007, 13h37
Antoun

Citation:

Envoyé par yiannis

bonjour,

il y a un truc que je ne comprends pas dans ta requête :?
tu déclare ton champs:

et tu lui passes NULL comme valeur 8O
Si ton champs est en auto_increment, tu n'as pas a lui passer de valeur, il va la prendre tout seul :roll:
Ca peu peut être, être la cause de ton problème.

Yiannis, sur le fond, tu as raison, mais il se trouve que MySQL accepte qu'on lui passe un NULL dans une colonne en auto-incrément. C'est la même chose que de lui donner DEFAULT (ce qui serait plus logique) où de ne rien lui passer du tout (ce qui est la façon normale de faire).
03/11/2007, 13h41
Antoun

Citation:

Envoyé par epeichette

ok alors contre toute attente, la réponse à

Code:

SELECT @@character_set_client ;

est utf_8. Je ne comprend pas pouquoi dans la mesure où dans my.ini j'ai latin1 de déclarer et que ma base comme l'ensemble de mes tables sont déclarés en "latin1_swedish_ci"

ça n'a rien à voir. @@character_set_client ne dépend que du client que tu utilises. MySQL QB et Toad for MySQL, par exemple, sont toujours en utf8.

Citation:

Envoyé par epeichette

D'où vient cet utf8 et surtout comment faire pour le passer en Latin 1?

Quel est donc ton client ?

Citation:

Envoyé par epeichette

Sinon, j'ai passé la requête indiquée et j'ai toujours le même message d'erreur 8O

Remplace le ç par un c, histoire d'être sûr que le problème soit là.
05/11/2007, 11h58
epeichette

Le problème vient indiscutablement du 'ç', en le remplaçant par "c" la requête passe correctement.
Je ne pense pas que cela vienne du client car j'ai le même client (phpmyadmin ou Navicat mysql) pour le server mysql 4 et le server mysql 5 et qu'il n'y a qu'avec mysql 5 que j'ai le problème d'insertion.
Avez vous une autre piste que je pourrais explorer?
05/11/2007, 14h21
Galevsky

Vi, il est normal que le pb ne remonte qu'avec une v5.0 et pas en v4.X, j'ai la même chose ici. Ceci-dit il s'agit bien du CHARSET défaillant (la v4.X réagissait très mal et ne remontait pas l'erreur). Il y a moyen de se débarasser du problème très salement en changeant le mode, du style sql-mode="MYSQL40" dans ton my.ini... mais à déconseiller dans le cas où ce n'est pas une raison de migration sur un serveur pro de prod'.

Tente un SET NAMES latin1 avec le client juste avant de lancer ta requête d'INSERT.

Gal'
05/11/2007, 14h32
epeichette

Effectivement en plaçant SET NAMES latin1 avant ma requête cela marche :lol:

Mais est-ce que cela veut dire que dans ma base il va falloir passer cette commande SET NAMES latin1 avant chaque insertion ou update?
Car c'est une nouvelle base, créer dans mysql5 à partir de phpmyadmin qui ne vient aucunement d'une migration.

Par ailleurs, sur le serveur de production, nous avons effectivement fait migrer les bases de mysql 4.11 en mysql 5 . Est ce que cela veut dire que nous risquons de rencontrer ce problème sur l'ensemble des bases du nouveau serveur Mysql5???

as tu de la doc concernant ce soucis, car c'est la première fois que l'on m'en parle
05/11/2007, 15h42
Galevsky

Je suis sur une mig d'une DB que je ne connais mais que je suis chargé de migrer de MySQLv4.0 vers MySQLv5.0. Je te racconte pas le bordel. D'abord je te conseille de te mettre en mode MYSQL40 afin de garder le même comportement de MySQL (c'est pas dit que ça ce soit vrai jusqu'au bout, car j'ai du changer deux trois trucs tout de même, mais vu que j'ai un accès via connector/J, et que tout est est mis-à-jour je ne peux pas te dire si ça vient du connector ou bien de la DB, car avant le n'avais aucun warning et que maintenant j'ai du rajouter un param à mon url de connexion: jdbcCompliantTruncation=false, chose qu'il n'y avait pas avant (les warnings sont complètement légitimes, ceci-dit c'est pas mon pb et avant ils n'apparaissaient pas, je veux juste que cela ait le même comportement)).

Voir ce thread

En tout cas en ce qui me concerne, dans le my.ini:

default-character-set=latin1
sql-mode="MYSQL40"

Avec les tables en CHARSET=latin1. De plus mon appli fait un SET NAMES latin1 (code java donc pas long de wrapprer la connexion), comme ça je suis peinard, voir ici pour le CHARACTER SET utilisé lors d'une connexion.

Vi le pb, tu vas te le bouffer sur l'ensemble des DB, car indépendemment des DB le client doit être en latin1, sinon tu pars au tas => SET NAMES dans l'appli est tu es certains que ton appli indique au server DB que ce qu'il va envoyer sera encodé en latin1.

Citation:

Envoyé par Manuel MySQL

Lorsque vous exécutez la commande SET NAMES ou SET CHARACTER SET, vous changez aussi la collation de la connexion. Cependant, la collation de connexion existe uniquement par cohérence. Généralement sa valeur n'a pas d'importance.

Avec le client mysql, il n'est pas nécessaire d'exécuter la commande SET NAMES à chaque démarrage. Vous pouvez ajouter l'option --default-character-set-name dans la ligne de commande de mysql, ou dans le fichier d'options. Par exemple, la ligne suivante est exécutée automatiquement à chaque démarrage de mysql :

[mysql]
default-character-set=koi8r

Dans mon cas le client n'est pas mysql.exe, mais mon appli web, donc autant te dire que....je ne pense pas que cette var puisse me servir.

Autre point important: je n'utilise que du MYISAM, et pas d'inno-db.

Gal'