Bonjour,
Lors d’un changement de serveur, j’ai voulu transférer la base de données de mon forum qui est assez lourde (environ 150 mo) ; je l’ai donc exporté à l’aide de mysql.
Maintenant que je veux l’importer sur le nouveau serveur, j’obtiens des erreurs.
J’ai essayé de faire l’importation avec bigdump mais aussi en ssh, rien n’y fait, j’obtiens toujours des erreurs mais à des lignes différentes.
Exple : ERROR 1064 at line 143380 : You have an error in your SQL Syntax ; check the manual that correspond to MySQL server version for the right syntax to use near….etc
Je ne pense pas avoir d’erreurs dans la base de données puisque j’avais déjà restauré celle-ci plusieurs fois sur l’ancien serveur.
Toutefois, lorsque j’ai importé une autre base de données (plus petite) et qui concernait le site en lui-même, tout c’est bien passé.
L’interclassement de la base de données à restaurer est « latin1_swedish_ci », je l’ai donc importé dans une base de données en « latin1_swedish_ci » mais j’ai aussi essayé d’autres choses, ca ne change rien.
Est-il possible au sein d’une même base de données d’avoir des charset différents ?
Il me semble que dans les 2 cas, c’était MySQL: 5.0.21 qui était utilisé, je précise aussi que le serveur est un dédié chez ovh avec Gentoo 2006.0
Je n’arrive pas à voir d’où vient le problème, quelqu’un pour m’aider ?
Je serais tenté de te conseiller de faire le test en local, en t'installant un WAMP par exemple sur ton pc.
150 Mo cela fait beaucoup, et peu d'hébergeurs acceptent une importation sql de cette taille, vérifie la contrainte de ton hébergeur à ce niveau.
Tu peux aussi faire un test en important uniquement la ligne qui est marquée en erreur (en considérant bien sûr que tu as avant importé la structure des tables).
Enfin, tes 150 MO, ce la taille du fichier sql brut, ou en gzip ?
Merci de ta reponse. Je vais essayer en local.
Je vais essayer de verifier la contrainte au niveau d'ovh, c'est vrai que j'ai l'impression que ce vient de la taille.
Concernant l'erreur sur la ligne, à chaque tentative d'import, j'ai une erreur differente et à des lignes completement differentes egalement, exple:
ERROR 1064 (42000) at line 57343: 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 '*(25312, 'Kanga', 3, 'Kanga@adidas-in-da-style.info', 1174491987, '127.0.0.1', 0' at line 2
ERROR 1054 (42S22) at line 51978: Unknown column 'bdayear' in 'field list'
ERROR 1064 (42000) at line 143380: 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 '*(7152, 0),
(7604, 0),
(7108, 0),
(7112, 0),
(7386, 0),
(7132, 0),
(7115, 0),
(7' at line 1709
A mon humble avis, il n'y a pas de raison que cela viennent de la taille. 150 Mo pour une base de données c'est trois fois rien.
D'autre part, si ça devait venir du fournisseur d'accès, ça m'étonnerait quand même que ça se manifeste par une erreur de syntaxe.
Malgré tout ce que tu as dit dans ton post initial, je pense que tu as bel et bien là un problème d'encodage et/ou de version MySQL. L'un ET l'autre n'étant pas impossible, voire probable. Il me semble même que le problème tel que tu le décris est assez fréquent avec MySQL.
AMHA il faudrait:
-exporter la base en utf-8. Ca doit être possible avec MySQL. Enfin il me semble, je dois avouer que je connais assez mal MySQL.
- exporter/importer en forçant la compatibilité avec une version précise de MySQL.
Enfin, je sais bien que ça ne va pas t'aider, mais PostgreSQL, c'est bien :)
Certe ce n'est pas beaucoup pour une base de données, mais il faut savoir que beaucoup d'hébergeurs limite un import SQL à 2 Mo dans PhpMyAdmin. D'autres à 50 Mo, d'autres à 100 Mo.
Il est possible que l'erreur de synthaxe soit aussi dû à un fichier tronqué.
Merci de votre aide.
Oui ca doit finalement bien venir d'une erreur de syntaxe.
Le probleme c'est que je n'ai plus acces à l'ancien serveur, je ne peux pas donc pas relancer d'export.
J'essaie actuellement d'editer ma base pour corriger les erreurs "à la main" mais c'est lourd à manipuler.
Est-il possible de decouper le fichier .sql ? ou d'extraire les tables de ce fichier une fois qu'il a été exporté?
Oui c'est en fait un simple fichier texte, tu peux l'éditer avec n'importe quel éditeur de texte (même le bloc note :-))
Tu peux par exemple découper le fichier par table, ou dans le cas d'une grande table (celle contenant les posts par exemple), tu peux découper les insert en pusieurs parties.
Peut être bien, c'est un monde que tu connais mieux que moi.
Mais il a dit qu'il a essayé en ssh. Je suppose que ça voulait dire avec les outils en lignes de commandes shell et mysql. Comme uploader le fichier et le faire incurgiter à mysql en direct avec un outil mysql.
Si c'est ça, je vous mal l'hebergeur limiter quoi que ce soit.
C'est malheureusement à craindre. J'ai déjà entendu parler de ça plusieurs fois à propos de MySQL.
C'est même pas une erreur de syntaxe, c'est tout simplement que MuySQL se mélange les nougats.
Oui normalement c'est un simple fichier texte.
A la main... hum, 150 Mo faut être courageux et patient. Et ne pas avoir peur d'introduire des erreurs supplémentaires parce que le boulot est fastidieux et que ça va forcément arriver.
Moi j'écrirasi un script qui filtre toutes les instructions charset
Ah oui aussi, lol :lol: tes bases proviennent de Linux si je comprends bien (j'ai lu gentoo quelque part)
Alors toutes les opérations je les ferais sous Linux. Parce que sous Windows les retours chariot ne sont pas les mêmes que sous Linux et qu'il est prudent de ne pas ajouter de difficultés potentielles.
Et j'éviterai le bloc note comme la peste pour la même raison :lol:
Rien ne vaut un script pour traiter ton problème. Mais si tu dois éditer du SQL "à la main", alors Emacs rules :)
En effet j'avais zappé ce détail :-)
Merci pour toutes vos réponses, il y avait pas mal d'erreurs dans la base.
J'ai fait appel à un professionnel qui m’a réparé tout ca !
Probleme réglé.