Discussion :

[lavercq]

Bonjour,
J'ai dans ma table un champ 'varchar' qui est limité à 255 caractères, c'est trop court pour certains articles.
Je souhaite modifier ce champ et le passer en blob.
Comment dois-je procéder ?
Merci pour votre aide

[flo.87]

Si tu as phpMyAdmin tu dois pouvoir éditer les champs de ta table dans l'onglet "Structure".

Sinon, essaie une commande du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ta_table CHANGE ton_champ ton_champ TEXT;

[lavercq]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER table_X CHANGE champ_X TEXT;

Je viens de faire ça, et voilà ce que MySQL répond :
MySQL a répondu:

#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

Question subsidiaire:
Pourquoi mettre TEXT et pas BLOB...?

[flo.87]

Tu fais erreur dans ton instruction. Il faut mettre que ta ligne soit constituée de "ALTER TABLE", puis le nom de ta table, puis "CHANGE", puis deux fois le nom de ton champ puis le type que tu veux lui mettre. Ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ta_table CHANGE ton_champ ton_champ TEXT;

La différence entre BLOB et TEXT, comme expliquée ici (deuxième paragraphe), est une question de sensibilité aux minuscules/majuscules.

[lavercq]

Tu fais erreur dans ton instruction. Il faut mettre que ta ligne soit constituée de "ALTER TABLE", puis le nom de ta table, puis "CHANGE", puis deux fois le nom de ton champ puis le type que tu veux lui mettre. Ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ta_table CHANGE ton_champ ton_champ TEXT;

La différence entre BLOB et TEXT, comme expliquée ici (deuxième paragraphe), est une question de sensibilité aux minuscules/majuscules.

Je viens de faire ce qui est indiqué, voici la réponse de MySQL:
MySQL a réponduocumentation
#1170 - BLOB column 'X' used in key specification without a key length

Qu'est-ce que cette key lenght vient faire ici ?

[Antoun]

ça veut dire que ta colonne est utilisée dans une clef... c'est possible avec un TEXT ou un BLOB, mais seulement à condition de préciser le nb de caractères à prendre en compte.

Dans tous les cas, il est parfaitement inutile de passer au TEXT. Le VARCHAR peut aller jusqu'à 65535 caractères... Dons par exemple, pour passer à 500 caractères :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ta_table CHANGE ton_champ ton_champ VARCHAR(500)

ou plus classiquement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE ta_table MODIFY ton_champ VARCHAR(500)

Juste pour expliquer la différence de syntaxe : CHANGE est surtout utilisé pour renommer la colonne, d'où le fait qu'on mette deux fois le nom.

[lavercq]

J'ai fait cette requête, et voici :
MySQL a répondu:
#1074 - Too big column length for column 'X' (max = 255). Use BLOB instead

Donc, j'ai refait la requête avec blob au lieu de varchar, résultat :
#1170 - BLOB column 'X' used in key specification without a key length

Nouvel essai après modification :
ALTER TABLE Y MODIFY champX BLOB (500);
réponse:
#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '(500)' at line 1

Merci pour vos réponses

[Antoun]

Quelle est ta version de MySQL ? Quel est le code de création de ta table ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT VERSION() ;
SHOW CREATE TABLE Y ;

[SQLpro]

Un index ne sert à rien sur une colonne de grande longueur. tant que vous persisterez à avoir cet index, comme le message de MySQL vous l'indique, vous ne pourrez pas modifier cette colonne.

A +

[lavercq]

Quelle est ta version de MySQL ? Quel est le code de création de ta table ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT VERSION() ;
SHOW CREATE TABLE Y ;

Voici quelle est la version de MySQL :
Version du client MySQL: 5.0.32
et voici le résultat de show create table `X` :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
CREATE TABLE `X` (
 `ID` int(11) NOT NULL auto_increment,
 `A` varchar(255) default NULL,
 `B` varchar(255) default NULL,
 `C` varchar(255) default NULL,
 `D` varchar(255) default NULL,
 `E` varchar(255) default NULL,
 `F` varchar(255) default NULL,
 `G` varchar(255) default NULL,
 `H` varchar(255) default NULL,
 `I` varchar(255) default NULL,
 `J` varchar(255) NOT NULL default '',
 `K` varchar(255) default NULL,
 `L` varchar(255) default NULL,
 `CID` int(11) default NULL,
 PRIMARY KEY  (`ID`),
 KEY `CID` (`CID`),
 KEY `D` (`D`),
 KEY `A` (`A`),
 KEY `B` (`B`),
 KEY `H` (`H`),
 KEY `F` (`F`),
 KEY `G` (`G`),
 KEY `E` (`E`),
 KEY `K` (`K`),
 KEY `L` (`L`),
 KEY `C` (`C`),
 KEY `ID` (`ID`)
) TYPE=MyISAM

Mais, je tiens à bien préciser que je n'ai jamais spécifié tous ces index lors de la création de la table...

[lavercq]

J'ai indiqué Version 5.0.32, mais je viens de remarquer qu'apparait en haut du résultat de ma requête show create table :

MySQL 4.0.25-standard-log
requête SQL: show create table `X`;

Alors, est-ce 5.0.32 ou 4.0.25, et cela a-t-il une conséquence dans le cas qui nous occupe ?

[lavercq]

Un index ne sert à rien sur une colonne de grande longueur. tant que vous persisterez à avoir cet index, comme le message de MySQL vous l'indique, vous ne pourrez pas modifier cette colonne.

A +

J'ai donc supprimé cet index...
J'espère que cela n'aura pas de conséquences regrettables sur les recherches à venir...
Il reste un bien grand nombre d'index !
Je ne comprend pas pourquoi...
Ce n'est pas de mon fait !
En fait, cette table X fait partie d'une base comprenant 4 tables,W,X,Y,Z .
L'une des tables tient trace des liaisons entre deux autres
J'espère que je suis clair...

[Antoun]

J'ai indiqué Version 5.0.32, mais je viens de remarquer qu'apparait en haut du résultat de ma requête show create table :

MySQL 4.0.25-standard-log
requête SQL: show create table `X`;

Alors, est-ce 5.0.32 ou 4.0.25, et cela a-t-il une conséquence dans le cas qui nous occupe ?

Je suppose que le client est 5.0.32 et le server 4.0.25. Ce qui expliquerait ton problème, car le VARCHAR était limité à 255 caractères en version 4. Tu peux vérifier la version du serveur avec cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT VERSION() ;

Par ailleurs, appeler une table X, avec des colonnes A à L, c'est quand même le meilleur moyen de ne rien comprendre à ce qu'il y a dans la table !

[lavercq]

Je suppose que le client est 5.0.32 et le server 4.0.25. Ce qui expliquerait ton problème, car le VARCHAR était limité à 255 caractères en version 4. Tu peux vérifier la version du serveur avec cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT VERSION() ;

Par ailleurs, appeler une table X, avec des colonnes A à L, c'est quand même le meilleur moyen de ne rien comprendre à ce qu'il y a dans la table !

Non...
J'ai changé les noms, pour des raisons de sécurité !
J'ai remarqué que tout ce qui paraît dans les forums était repris par les moteurs de recherche...

[lavercq]

Voici la réponse à la question de la version :
4.0.25-standard-log

Pourrais-je augmenter la taille de ce champ qui actuellement n'accepte que 255 caractères...?

[Antoun]

Voici la réponse à la question de la version :
4.0.25-standard-log

Pourrais-je augmenter la taille de ce champ qui actuellement n'accepte que 255 caractères...?

Non, pas en VARCHAR. Il faut effectivement le passer cette colonne en TEXT, ce qui implique de faire sauter l'index. Si jamais tu as besoin de cet index, tu pourras ensuite le recréer en précisant le nb de caractères à prendre en compte, par ex.:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
CREATE INDEX trucmuche ON X (A(500)) ;

Ceci dit en rappellant les réserves de SQLpro sur ce genre d'index :

Un index ne sert à rien sur une colonne de grande longueur.

Il reste un bien grand nombre d'index !
Je ne comprend pas pourquoi...
Ce n'est pas de mon fait !

Je t'inviterai bien à faire sauter tout ça, quitte à recréer ensuite ceux qui sont vraiment nécessaires

En fait, cette table X fait partie d'une base comprenant 4 tables,W,X,Y,Z .
L'une des tables tient trace des liaisons entre deux autres
J'espère que je suis clair...

La création d'une FOREIGN KEY entraîne celle d'un index sur les deux tables liées. Ceci dit, ces FOREIGN KEYs ne fonctionnent que si les deux tables sont en InnoDB, tandis que la tienne est en MyISAM...

Non...
J'ai changé les noms, pour des raisons de sécurité !
J'ai remarqué que tout ce qui paraît dans les forums était repris par les moteurs de recherche...

OK, je comprends mieux.

[lavercq]

Je voudrais soumettre à votre jugement une idée...
Pensez-vous que je puisse modifier en local la structure de ma table puis la renvoyer à mon hébergeur ?
J'ai xampp sous windows sur mon PC...
Il n'y aura plus ce problème de version puisque xampp répond à
SELECT VERSION() ; :
5.0.21-community-nt

Qu'en pensez-vous ?
Est-ce une solution ?
Merci pour vos conseils et votre aide.

[Antoun]

Je voudrais soumettre à votre jugement une idée...
Pensez-vous que je puisse modifier en local la structure de ma table puis la renvoyer à mon hébergeur ?

non

[lavercq]

Je ne comprend pas ce non, sec et cassant...!
Pourquoi non...?
j'ai pu modifier en local, il ne me reste qu'à renvoyer à mon hébergeur...
Qu'est-ce qui peut foirer là-dedans Antoun ?

[Antoun]

Désolé, je ne voulais être ni sec ni cassant, mais juste répondre à ta question, et je dois reconnaître que j'ai un peu manqué d'imagination quant aux explications

Comment dire... Imaginons que tu aies un congélateur de 100 litres, et ton serveur un congélateur de 50 l. Même si tu prépares une glace de 80 l chez toi, tu n'arriveras pas pour autant à la faire rentrer dans le congélateur de ton serveur...