Migration InnoDB vers MyISAM impossible ?

Bonjour,

J'ai un soucis qui me perturbe. J'ai remarqué que l'hébergement Free de MySQL ne permet la génération de tables que dans le type MyISAM et quelques autres que sans doute personne n'utilise. Malheureusement pour moi, la base de donnée source, MySQL elle aussi mais chez moi à la maison a été créée sur le type de tables InNODB.
J'aimerai "dupliquer" la base qui se trouve chez moi (en InnoDB) vers ma base hébergée chez Free (en MyISAM). J'ai voulu utiliser phpMyAdmin pour simplement exporter au format fichier texte SQL la base qui se trouve chez moi (en InnoDB) et ensuite l'importer dans ma base free... Et là, paf le chien. Lorsque je réalise l'opération d'importation via phpMyAdmin sur la base Free (qui ne supporte pas l'InnoDB), seule la plus petite de mes tables s'importe et est normalement transformée en type MyISAM, mais dés la seconde table, j'obtient le message d'erreur suivant :

Citation:

---

MySQL a repondu :

#1071 - Specified key was too long; max key length is 1000 bytes

---

Il semblerait que cela soit lié à la valeur de l'indexe, mais je n'y comprends rien. Pour précision, voici la structure de ma table InnoDB sur mon serveur personnel :

Citation:

---

Table : Emprunteurs (InnoDB)

champ 'Indexe', type int(4), Non null Clé primaire auto-incrémentée
champ 'Nom', type varchar(255) Non null chaîne vide par défaut
champ 'Prenom', type varchar(255) Non null chaîne vide par défaut
champ 'Service', type varchar(255) Non null chaîne vide par défaut
champ 'Telephone', type varchar(255) null possible valeur NULL par défaut
champ 'Email', type varchar(255) null possible valeur NULL par défaut

---

Cette table contient 741 enregistrements, et la valeur de l'indexe varie entre 8 et 1156.

Quelqu'un pourrait-il m'aider à comprendre, je ne m'en sort pas avec les explications que je trouve sur le site MySQL...

Merci.

Je pense que tu confonds index et clé auto-incrémenté...

Que te donne la requête suivante ?

Code:

---

show index from Emprunteurs ;

---

Voilà le résultat de la requete que vous m'avez proposé :

Code:

---

1 2 3

emprunteurs 0 PRIMARY 1 Indexe A 741 NULL NULL BTREE emprunteurs 1 Nom 1 Nom A 741 NULL NULL BTREE

---

Je n'y pércise pas les noms des colonnes. En fait, je ne sais pas comment copier/coller le résultat affiché dans phpMyAdmin pour vous le présenter tel qu'il apparaît. Je ne copie/colle que les lignes contenues dans le tableau.
Mais je penses que vous connaissez la nature de chacun de ces champs, sinon voici les noms de colonnes dans l'ordre :

Table, Non_unique, Key_name, Seq_in_index, Column_name, Collation, Cardinality, Sub_part, Packed, Null, Index_type

Je crois avoir compris. Cela vient du fait que mon champ Nom, un champ de type VARCHAR définit sur une longueur de 255 caractères avec une internationalisation fixée en UTF8, a été définit en tant qu'indexe. D'après ce que j'ai compris des explications trouvées sur le site de MySQL, l'encodage UTF8 necéssite trois octets par caractères. Bref, j'ai fait un petit test qui me permet d'éviter l'erreur lorsque j'importe mon fichier sql en précédant son exportation depuis la base source d'une modification de l'encodage de mes tables en Latin1 par exemple. Maintenant, je vais voir si l'import échoue toujours sans toucher à l'encodage, mais en supprimant l'indexe associé au champ VARCHAR.

Je vous tiens au courant...

J'ai refait un test. Je pars de ma base source, celle qui travaille avec des tables de type InnoDB. Avant d'exporter cette table, je supprime l'indexes que j'avais positionné sur le champ Nom, puis j'exporte la table dans un fichier sql nommé emprunteurs.sql. Ensuite, je me connecte sur ma console phpmyadmin chez Free pour accéder à la base de données hébergée chez eux dans laquelle je veux importer emprunteurs.sql. Je précise que dans ce cas, sur le serveur MySQL de free, InnoDB n'est pas supporté, donc les tables sont importées en MyISAM. Et bien, sans l'indexe aucuns problèmes. Je peux importer mon fichier, tout en conservant l'encodage UTF8 avec une longueur de 255 caractères sur le champ Nom de cette table. Le plus commique, c'est qu'une fois la table importée, au format MyISAM donc, je peux remettre en place ces indexes sans problèmes. Je les avais éffectivement ajouté dans le but d'optimiser les temps de réponses pour des requetes SQL de regrouppement.
Je penses que l'usage du format SQL pour le fichier emprunteurs.sql généré lors de l'exportation n'est pas le plus pertinent dans ce cas. Je n'ai malheureusement plus le temps de voir si ça fonctionnerai directement en choisissant un autre format.
Merci en tout cas, Antoun, de vous être penché sur mon problème.

Bonjour
j'ai le même souci si vous avez une solution

cordialement