Discussion :

[Freedolphin]

Bonjour à tous,

Comme d'autres, j'imagine, je dois migrer ma BDD chez OVH pour passer de la version Mysql4 à la version Mysql5.6.
Or je rencontre un problème : impossible d'exporter la base depuis phpMyAdmin, ni même d'effectuer un dump en php sur le serveur. Les fichiers sont toujours corrompus.
En cause (à mon avis) : les accents. En effet, lorsque je regarde le contenu des colonnes sur phpMyAdmin, celles contenant des données accentuées sont vides (alors qu'en ligne tout apparaît correctement).
Il n'y a pas d'interclassement sur cette vieille version de Mysql, je ne sais donc pas quoi faire.
Auriez-vous une idée et une piste de solution ?
Merci d'avance !

[Michel.Priori]

Bonsoir,

MySQL est passé en licence GPL à partir de la version 3.23.19 (juin 2000)
Version 4.0 : première version en octobre 2001, stable depuis mars 2003
Version 4.1 : première version en avril 2003, stable depuis octobre 2004
Version 5.0 : première version en décembre 2003, stable depuis octobre 2005
Version 5.1 : première version en novembre 2005, Release Candidate distribuée depuis septembre 2007
Version 5.2 : distribuée en avant-première (ajout du nouveau moteur de stockage Falcon) en février 2007, cette ligne a ensuite été renommée 6.0
Version 5.5 : Version stable depuis octobre 2010
Version 5.6 : Version stable depuis février 2013
Version 5.7 : Version stable depuis octobre 2015
Version 6.0 : première version alpha en avril 2007, abandonnée depuis le rachat de MySQL par oracle en décembre 2010
Version 8.0 : Version stable depuis avril 2018

Attention à ne pas migrer trop rapidement, passer d'une version de 2001 à celle de 2013 c'est une sacré prise de risque.

[Freedolphin]

Merci pour ces infos mais ça ne répond pas du tout à ma question
Quant à la prise de risque, je n'ai pas le choix, c'est une demande d'OVH.

[Michel.Priori]

Bonjour,

Ce qui m'étonne c'est que les cadors de mysql ne se soient pas rués sur le post.
Etrange

Je ne me considère pas comme une référence en admin Mysql.
Alors j'ai fais une recherche sur le web.
Est-ce que ça ne répondrait pas au problème ?

https://stackoverflow.com/questions/...dump-with-utf8
https://www.whitesmith.co/blog/latin1-to-utf8/

Si oui, merci de faire un retour.

Ps : OVH ne permet pas de passer à une version plus récente que la 5.6 ?

[amateurprg]

Salut

Quand tu dis qu'il n'y a pas d'interclassement, ça veut dire que tu peux pas définir la base en UTF8 ?

Si c'est ça y a que ces solutions :

- Changer de base : peut-etre que tu peux en installer une sur ton site et pas te servir de celle de l'hebergeur.
- Sauver tes chaines accentuées sans accents mais formatées de telle sorte qu'à la lecture par php celui-ci détecte le caractère spécial qui indique que la lettre suivante a tel accent et php la traduit en chaine accentuée.
- Tout sauver sans accents.
- Changer d'hebergeur s'il ne regle pas ton probleme.

[Artemus24]

Salut à tous.

De votre ancienne base, il nous faudrait le descriptif de la table qui pose problème.

Il n'y a pas d'interclassement sur cette vieille version de Mysql, je ne sais donc pas quoi faire.

Dans le fichier "my.ini", n'avez-vous pas de "default-character-set" ?
Pourquoi votre base de données a été définie sans charset et collate ?

Pour résoudre ce problème, forcez vos tables à un charset.
Oui mais lequel car il y a eu des évolutions depuis la version mysql 4.0.

Auriez-vous une idée et une piste de solution ?

Oui.

1) identifiez le charset et le collate que vous désirez utiliser.
Pourquoi pas choisir comm charset du "latin1" et comme collate du "latin1_general_ci" si vous utilisez que le français, voire aussi l'anglais.

2) en principe, dans les nouvelles versions de mysql, on utilise le charset "utf8mb4" et le collate "utf8mb4_unicode_ci".
Sauf que cela n'exitait pas dans la version mysql 4.0.

3) forcez le charset et le collate lors du chargement de votre base de données. Comment ?
Soit par "mysqldump" en ligne de commande comme l'a indiqué "Michel.Priori" dans son message #4.

4) soit en utilisant "phpmyadmin", en faisant un export.
Mais il faudra forcer la configuration de cet export en sélectionnant le charset que vous désirez utiliser.

5) avez-vous à votre disposition le phpmyadmin qui correspond à la version mysql 4.0 ?
Peut-être la version phpmyadmin 4.4.15 ?
Je dis cela car le phpmyadmin est toujours aligné sur la version mysql lui correspondant.
Utilisez une version phpmyadmin plus récente peut provoquer des problèmes.

6) dans la nouvelle version mysql 5.6, utilisez la dernière version phpmyadmin, qui est la 4.9.0.1.

7) faire ensuite un import dans la nouvelle version phpmyadmin de votre hébergeur.

8) ne pas oublier de définir dans le fichier "my.ini" deux choses :
--> le charset par defaut ("default-character-set").
--> et le "init-connect = 'SET NAMES latin1 COLLATE latin1_general_ci'".
Si le latin1 ne vous convient pas mettez "utf8" et "utf8_general_ci".

@+

[Freedolphin]

Changer de base : peut-etre que tu peux en installer une sur ton site et pas te servir de celle de l'hebergeur.

Merci pour ces conseils mais il serait judicieux de lire les messages intégralement. Je suis précisément en train de changer de base, puisque l'idée est de passer d'une BDD installée sur Mysql4 à une nouvelle, installée sur Mysql5.6.

[Freedolphin]

Est-ce que ça ne répondrait pas au problème ?

https://stackoverflow.com/questions/...dump-with-utf8
https://www.whitesmith.co/blog/latin1-to-utf8/

Si oui, merci de faire un retour.
Ps : OVH ne permet pas de passer à une version plus récente que la 5.6 ?

Non, OVH ne propose que la 5.6.
J'ai regardé ton lien et modifié mon dump de cette façon, mais sans succès :

Code :

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

mysqldump --no-tablespace --default-character-set=utf8 --opt -h%s -u%s -p"%s" %s | gzip > dumpDB.sql.gz

[Freedolphin]

De votre ancienne base, il nous faudrait le descriptif de la table qui pose problème.

Dans le fichier "my.ini", n'avez-vous pas de "default-character-set" ?
Pourquoi votre base de données a été définie sans charset et collate ?

Merci pour ces conseils. La BDD a été définie ainsi à l'époque (mais ça remonte à loin).
Voici quelques infos la concernant :
Version du serveur: 4.0.26-standard-log
Version du client MySQL: 5.5.62
Langue : Français iso-8859-1 (mais en utf-8 ça ne change rien)

Je n'ai pas de fichier my.ini, je ne vois pas comment y avoir accès ou si c'est à moi de le créer.

[Artemus24]

Salut Freedolphin.

Langue : Français iso-8859-1 (mais en utf-8 ça ne change rien)

C'est donc du latin1 que vous utilisez !

Avez-vous utilisé dans phpmyadmin, la méthode d'exportation qui consiste à personnaliser les options ?

--> Sélectionnez ISO-8859-1 !
--> Dans "Maximiser la compatibilité avec un système de base de données ou un ancien serveur MySQL :", sélectionnez "MYSQL40".

Et faites à nouveau une tentative.

Je n'ai pas de fichier my.ini, je ne vois pas comment y avoir accès ou si c'est à moi de le créer.

Vous avez nécessairement un fichier "my.ini". C'est celui de ovh mais vous n'aurez pas la possibilité de le modifier.

Donnez le résultat de votre export, juste la partie qui plante.

Dois-je aussi comprendre que vous n'avez jamais effectué de sauvegarde de votre base de données ?

@+

[Freedolphin]

Je ne peux pas personnaliser ce type d'option lors de l'export, comme le montre cette capture :


Je sauvegardais régulièrement et automatiquement la base avec un dump lancé par une tâche cron, mais je réalise aujourd'hui que la partie "données" était toujours vide.

Je n'ai pas d'erreur à l'export, mais à l'import :

Erreur

Requête SQL :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE `categorie` (
  `id` int(11) NOT NULL auto_increment,
  `nom` varchar(80) NOT NULL default '',
  `description` text NOT NULL,
  `image` text NOT NULL,
  PRIMARY KEY  (`id`)
) TYPE=MyISAM

MySQL a répondu : Documentation
#1064 - Erreur de syntaxe près de 'TYPE=MyISAM' à la ligne 7

[Artemus24]

Salut Freedolphin.

Je ne peux pas personnaliser ce type d'option lors de l'export, comme le montre cette capture :

ovh a bridé les fonctionnalités de l'export. C'est complètement idiot d'avoir fait cela.

Je sauvegardais régulièrement et automatiquement la base avec un dump lancé par une tâche cron, mais je réalise aujourd'hui que la partie "données" était toujours vide.

Du coup, les sauvegardes ne vous servent à rien puisque en l'état, vous ne pouvez pas les utiliser.

L'erreur est sur la ligne ") TYPE=MyISAM". Il faut écrire ") ENGINE=MyISAM".

Pour faire manuellement un export, utilisez ceci :

Code :

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

mysqldump --no-create-db  --opt  --databases le_nom_de_votre_base_de_données  --result-file=fichier.sql

Le mieux serait de prendre contact avec ovh afin de savoir comment procéder pour migrer votre base de données de mysql 4.0 vers mysql 5.6.

@+

[Freedolphin]

Le mieux serait de prendre contact avec ovh afin de savoir comment procéder pour migrer votre base de données de mysql 4.0 vers mysql 5.6.

C'est bien évidemment ce que j'ai fais dès le départ, mais le support m'a renvoyé vers leur page indiquant le processus de migration, c'est à dire export puis import, mais sans aucun réglage particulier qui permette de faire face à mon problème.

Je vais tester ta ligne de commande, merci.

[Freedolphin]

Pour faire manuellement un export, utilisez ceci :

Code :

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

mysqldump --no-create-db  --opt  --databases le_nom_de_votre_base_de_données  --result-file=fichier.sql

Ca ne donne rien, le fichier fait 0 octet.
Je pense que je vais écrire un code maison en php pour extraire les données dans un fichier texte, table par table. Ce sera finalement le plus simple !

[amateurprg]

Moi :

- Sauver tes chaines accentuées sans accents mais formatées de telle sorte qu'à la lecture par php celui-ci détecte le caractère spécial qui indique que la lettre suivante a tel accent et php la traduit en chaine accentuée.
- Tout sauver sans accents.
- Changer d'hebergeur s'il ne regle pas ton probleme.

Toi :

Merci pour ces conseils mais il serait judicieux de lire les messages intégralement. Je suis précisément en train de changer de base, puisque l'idée est de passer d'une BDD installée sur Mysql4 à une nouvelle, installée sur Mysql5.6.

Ces trois idées que je t'ai proposé étaient valables et le sont encore, choisi la plus facile, car je pense pas que ovh va t'écouter, sinon ils n'auraient pas rendus si difficile la migration.

[Freedolphin]

Pour ceux qui seraient confrontés au même problème, je vous donne ma solution (qui vaut ce qu'elle vaut) mais qui a le mérite d'être efficace.
Comme la base n'était pas énorme, j'ai généré un fichier sql pour chaque table, ce qui m'a permis d'importer les données proprement dans la nouvelle BDD.
En voici le code :

Code php :

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
<?php
connexion à la base (fichier de config ou données)
 
$fichier = "INSERT INTO `table` (`colonne1`, `colonne2`) VALUES ";
 
// extraction des donnees
$sql = mysql_query("SELECT * FROM table ORDER BY colonne1 ASC");
while($data = mysql_fetch_assoc($sql))
{   
.colonne1 = $data["colonne1"];
$colonne2 = mysql_real_escape_string($data["colonne2"]); //si ce champ comporte des caractères spéciaux
$fichier .= "(\"$colonne1\", \"$colonne2\"),";	
}//fin du while
 
$fp = fopen("bdd.sql", 'w+');
fputs($fp, $fichier);
fclose($fp);
 
echo '<br><div align="center">Fichier enregistré<br><br><a href="bdd.sql">> voir le fichier</a></div>';
?>

Placez ce fichier php sur votre serveur, lancez-le puis récupérez le fichier sql sous forme de fichier texte.
A la fin du fichier, remplacez la dernière virgule par un point-virgule. Copiez-collez le tout dans une requête sql de la base et le tour est joué.

Et, oui, je sais, pour les puristes, remplacez mysql (obsolète) par mysqli, sauf si vous êtes aussi sur une ancienne version de php

[SQLpro]

Oui, c'est sûr qu'avoir mis 5 jours pour restaurer une base MySQL c'est efficace….
Moi avec du SQL Server je met quelques minutes seulement pour une base de 100 GO….. Depuis la version 2008 jusqu'à la version 2017.

A +

[Freedolphin]

Et bien il fallait venir nous donner des éléments de solution, si tu es si doué...
Pour info, ça ne m'a pris que quelques minutes également.

[Artemus24]

Salut Freedolphin.

Vous avez trop tardé pour faire votre migration.
Même pour les forums de type phpbb, il est conseillé de passer par les versions intermédiaires pour faire une migration.
Il aurait fallu avoir la version du phpmyadmin qui est associé à la version MySql 4.0 pour effectuer l'export.
Ca m'est déjà arrivé de rencontrer des problèmes avec phpmyadmin quand celui-ci n'est pas en phase avec la version MySql que j'utilise.

En ce qui me concerne, à chaque changement de version MySql, j'utilise phpmyadmin pour faire un export puis un import.
Je n'attends pas aussi longtemps que vous pour faire une migration.
Heureusement que vous avez trouvé la solution pour résoudre votre problème.

Passez votre sujet à résolu !

@+

[Freedolphin]

Je le saurai pour la prochaine fois en effet, j'avoue ne m'être pas beaucoup inquiété, je gère plusieurs BDD chez d'autres hébergeurs et je n'ai pas ce problème.
Merci pour ces précisions.
Le sujet est déjà résolu
Très bonne journée !