Discussion :

[ribotb]

Bonjour à tous,

Je suis en train de migrer sous MySQL des databases HSQLDB créées avec OpenOffice.org. La plupart de mes tables possèdent une clé primaire auto-incrémentée. Certaines tables sont en relation (1-n), une clé étrangère d'une table contenant la valeur de la clé primaire auto-incrémentée de la table liée.

Pour la migration j'ai désactivé l'auto-incrémentation des tables cible pour ne pas modifier les valeurs des clés primaires.

Mon idée était donc qu'après avoir rempli mes tables MySQL (je suis passé par un fichier intermédiaire au format csv) , je réactivais l'auto-incrément et le faisais redémarrer après la dernière valeur.

Mais je n'arrive pas à réactiver l'auto-incrémentation (par ALTER TABLE). Ce n'est peut-être pas possible ?

Merci de votre aide,
Bernard Ribot

[CinePhil]

Quelle requête as-tu essayé ? Quelle erreur as-tu obtenu ?

[ribotb]

Quelle requête as-tu essayé ? Quelle erreur as-tu obtenu ?

Bonsoir,

Pour préciser un peu ce que j'ai fait j'ajouterais que :
- j'ai créé des fichiers au format csv à partir de mes tables HSQL
- j'ai créé "a la mano" les tables sous MySQL mais sans activer l'auto-increment au niveau des clés primaires
- j'ai chargé mes tables MySQL avec un LOAD DATA
- et enfin j'ai voulu réactiver l'auto-increment par un ALTER TABLE tb1 CHANGE id AUTO_INCREMENT (c'est un peu "au pif" que j'ai essayé ça ! j'avoue n'avoir rien trouvé de ce genre dans la doc MySQL). Ca s'est bien évidemment terminé par une erreur de syntaxe (1064).

Je viens de recréer mes tables MySQL avec auto-increment cette fois-ci et refait le chargement. En fait j'ai vu qu'il n'y avait pas trop de dégats. Au départ je craignais que le LOAD me renumérote mais clés. Mais ce n'est pas le cas (les "trous" d'origine y sont encore). Par contre, le 1er enregistrement de chaque table qui avait l'id 0 (HSQL débute par défaut l'auto-increment à 0) a été supprimé (MySQL semble quant à lui débuter à 1).

Bernard

[CinePhil]

Donc problème ?

[ribotb]

Bonjour,

Je dirais : oui et non. Oui, parce que je vais pouvoir terminer ma migration. Non parce que ma question initiale est restée sans réponse : est-ce que réactiver l'auto-increment est possible et si oui, comment ? (quelle instruction SQL par exemple faudrait-il coder pour le faire).

J'attends une journée avant de mettre "résolu".

Bonne journée,
Bernard

[CinePhil]

Un petit tour dans la doc :

Pour ajouter une nouvelle colonne AUTO_INCREMENT nommée c :
mysql> ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD INDEX (c);
Notez que nous avons indexé c, car les colonnes AUTO_INCREMENT doivent être indexées, et que nous définissons aussi c en tant que NOT NULL, car les colonnes indexées ne peuvent être NULL.
Quand vous ajoutez une colonne AUTO_INCREMENT, les valeurs de la colonne sont remplies automatiquement pour vous. Vous pouvez choisir la valeur de départ pour l'indexation en utilisant SET INSERT_ID=# avant ALTER TABLE ou en utilisant l'option AUTO_INCREMENT = # de la table. See Section 13.5.2.8, « Syntaxe de SET ».
Avec les tables de type MyISAM, si vous ne changez pas la colonne AUTO_INCREMENT, l'indice d'auto-incrémentation ne sera pas affecté. Si vous effacez une colonne AUTO_INCREMENT puis en ajoutez une autre, l'indexation recommencera à partir de 1.

Quand tu veux modifier une colonne pour la passer en auto-incrément, il faut que cette colonne soit indexée et je crois qu'il faut redonner toute la structure de la colonne, comme l'exemple un peu plus haut dans la doc :

Pour changer une colonne a de INTEGER en TINYINT NOT NULL (en laissant le même nom), et pour changer une colonne b de CHAR(10) à CHAR(20) et la renommant de b en c :
mysql> ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
Pour ajouter une nouvelle colonne TIMESTAMP nommée d :

[ribotb]

Ca y est j'ai trouvé la bonne syntaxe :

Code :

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

1
2
ALTER TABLE tb1 
MODIFY id INT NOT NULL AUTO_INCREMENT;

Effectivement il faut redonner certains attributs (INT, NOT NULL). Certains seulement parce que si je redonne UNSIGNED par exemple, ça provoque une erreur de syntaxe "near unsigned".

En plus je m'étais complètement planté : j'avais codé CHANGE au lieu de MODIFY !

Merci de ton intérêt pour mon problème que j'ai pouvoir marquer comme "résolu".

Bonne fin de journée,
Bernard

[CinePhil]

Certains seulement parce que si je redonne UNSIGNED par exemple, ça provoque une erreur de syntaxe "near unsigned".

Tu peux donner la requête que tu avais essayée avec UNSIGNED ?

Parce que quand MySQL donne une erreur de syntaxe "near UNSIGNED...", ça veut dire que la syntaxe est mauvaise juste avant UNISGNED !

Quand tu veux préciser UNSIGNED pour une colonne, il faut préciser aussi son type :
INT UNSIGNED

[ribotb]

C'était tout simplement :

Code :

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

1
2
ALTER TABLE tb1 
MODIFY id INT NOT NULL UNSIGNED AUTO_INCREMENT;

Un problème dans l'ordre des attributs ?

[CinePhil]

Oui je pense que c'est plutôt ceci :

Code :

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

1
2
ALTER TABLE tb1 
MODIFY id INT UNSIGNED NOT NULL  AUTO_INCREMENT;

UNSIGNED est une précision sur le type INT.