Erreur SQL 1064 - Erreur d'importation
J'ai exporté une base de données en tant que sauvegarde qui fonctionnait bien. Lorsque j'ai importé la base de données sur le même serveur, dossier, etc., j'ai eu cette erreur:
Il est possible que vous ayez trouvé un bogue dans l'analyseur SQL. Veuillez examiner votre requête de près et vérifier que les guillemets sont Corrects et ne correspondent pas. D'autres causes d'échec possibles peuvent être que Vous téléchargez un fichier contenant des fichiers binaires en dehors d'une zone de texte citée. Vous pouvez également essayer votre requête sur l'interface de ligne de commande MySQL. La sortie d'erreur de serveur MySQL ci-dessous, le cas échéant, peut également vous aider à diagnostiquer le problème . Si vous avez toujours des problèmes ou si l'analyseur Échoue là où l'interface de ligne de commande réussit, veuillez réduire l'entrée de votre requête SQL à la requête qui pose problème et soumettre un bogue . rapport avec le bloc de données dans la section CUT ci-dessous: [. .____] [. .____] ---- ---- BEGIN CUT eNo1jUEKwjAURIXu/inmADHkpwYxu1JCu0iTmFQ9gYtushP09qaCs3oMjxmXc8wWI2PU8C5YMDSY [. .____] qayt7oiWT7l6CyON7NWxV5LpVjJiERgmF1aBu2vmY6sY5xwX11Ql9YXSMlicGhtKc9otEcs + 1ES + w2/19SY/hMniWen3Qd3hny8nMiDI ---- FIN DE COUPE ---- ---- BEGIN RAW ---- ERREUR: C1 C2 LEN: 1 2 11 STR:
MySQL: 5.5.30-30.1 USR OS, AGENT, VER: Win CHROME 5.0.29 PMA: 4.0.5 PHP VER, OS: 5.3.17 Linux LANG: en SQL:
---- FIN RAW ----Requête SQL:
MySQL a dit: Documentation
# 1064 - Vous avez une erreur dans votre syntaxe SQL; vérifiez le manuel correspondant à la version de votre serveur MySQL pour connaître la syntaxe à utiliser près de '' à la ligne 1
Le seul problème semble être qu'il manque du contenu à ma page d'index, le contenu principal en fait. Tous ces fichiers sont des fichiers .sql.
J'ai ensuite supprimé toutes mes tables et importé la base de données originale d'avril de l'année dernière. Il est évident que cette base de données manque toutes les informations de compte, les informations de commande, etc. pour tous mes clients, ainsi que toutes les modifications apportées à mes produits.
Lorsque je compare les deux bases de données, les 11 premières lignes semblent poser problème, mais je ne sais pas comment le résoudre. Les 11 premières lignes du fichier qui ne fonctionnent pas sont:
-- phpMyAdmin SQL Dump
-- version 4.0.5
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Sep 22, 2013 at 01:28 PM
-- Server version: 5.5.30-30.1
-- PHP Version: 5.3.17
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
Les 11 premières lignes du fichier qui fonctionne sont:
-- phpMyAdmin SQL Dump
-- version 3.4.10.1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Apr 09, 2012 at 05:50 AM
-- Server version: 5.1.61
-- PHP Version: 5.2.17
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
J'ai simplement essayé de copier et coller les 11 lignes du fichier de travail dans le fichier qui ne fonctionne pas et obtenir une autre erreur.
Je sais que c'est un long post et je m'excuse, mais cela fait des heures que je lutte avec cela et j'ai vraiment besoin d'aide.
Merci
OK, alors voici ce que j'ai trouvé, enfin. Lorsque j'ai ouvert le fichier qui me donnait l'erreur dans notebook +, la dernière ligne comportait bien entendu les éléments suivants:
ETXNULNULNULNULNULNULNULNULNUL
La base de données de travail d'origine à l'ouverture ne comportait aucun de ces caractères.
Lorsque j'ai simplement supprimé la dernière ligne du fichier qui m'indiquait l'erreur et importé la base de données, tout a bien fonctionné. Cependant, ma page d'accueil n'était toujours pas affichée correctement. J'ai appliqué une solution de contournement pour l'instant et vais essayer de comprendre cela plus tard.
J'espère que ça aidera quelqu'un.
J'ai eu le même problème lors de l'exportation de ma base de données pour un site Joomla 2.5. Cela a quelque chose à voir avec la compression dans phpmyadmin. J'ai changé la compression de "aucune" en "zippée" avant l'exportation la base de données et qui l'a résolu.
J'espère que cela pourra aider!
Dans mon cas, j'ai besoin de changer la compression enNONEet le mode de compatibilité SQL enANSI. J'exportais la base de données WordPress sur un autre serveur.
Comme il semble y avoir beaucoup de raisons qui pourraient déclencher cette erreur. Je voulais simplement partager mon problème et la solution de contournement que j'ai trouvée, espérons que cela ferait gagner un peu de temps. J'ai moi aussi rencontré ce problème lors de l'importation d'une base de données vers MySql. J'avais exporté une version d'une base de données à partir de mon ordinateur local et je voulais l'importer sur le serveur où mon site Web est hébergé. Le problème était qu’il y avait une discordance entre les versions des deux systèmes. J'ai réussi à contourner le problème en utilisant l’option de compatibilité (lors de l’exportation et lors de l’importation). J'ai utilisé "MYSQL323". Cela a résolu mon problème. Je pense que c'est une bonne solution pour ceux qui ont la possibilité de créer une nouvelle version exportée de la base de données.
J'ai corrigé cette erreur une minute auparavant. Lorsque vous exportez un fichier sql.gz, essayez de l'extraire. Le fichier extrait est toujours compressé, mais le fichier bu * .sql. Essayez d'ajouter à nouveau * .sql.gz et d'importer le fichier renommé. Cela fonctionnera.
Ce que j'essaie de dire, c'est que phpMyAdmin compresse le fichier deux fois.
J'ai eu le même problème lors de l'importation d'un fichier CSV et j'ai compris que certaines des colonnes vierges de la conversion Excel étaient vides. Lorsque j'ai sélectionné la première ligne comme nom de colonne à importer, il a essayé de créer plusieurs colonnes sans nom unique approprié.
Ma solution était: Comment
;mbstring.func_overload = 2
dans /etc/php5/Apache2/php.ini
C'est un bug dans phpMyadmin
Voici une solution temporaire
http://sourceforge.net/p/phpmyadmin/bugs/4095/#7e0c
ou quelque chose comme ça:
remplacez "PMA_Response :: getInstance () -> disable ();" "// PMA_Response :: getInstance () -> disable ();" - /path_to_phpMyAdmin/export.php
J'ai eu une ligne vide à la fin du fichier de vidage. Supprimer la ligne a résolu mon problème.