Błąd SQL 1064 - Błąd importu

Question

Wyeksportowałem bazę danych jako kopię zapasową, która działała poprawnie. Kiedy importowane do bazy danych do tego samego serwera, folderu dokładnym itp mam ten błąd:

There is a chance that you may have found a bug in the SQL parser. Please examine your query closely, and check that the quotes are correct and not mis-matched. Other possible failure causes may be that you are uploading a file with binary outside of a quoted text area. You can also try your query on the MySQL command line interface. The MySQL server error output below, if there is any, may also help you in diagnosing the problem. If you still have problems or if the parser fails where the command line interface succeeds, please reduce your SQL query input to the single query that causes problems, and submit a bug report with the data chunk in the CUT section below: ----BEGIN CUT---- eNo1jUEKwjAURIXu/inmADHkpwYxu1JCu0iTmFQ9gYtushP09qaCs3oMjxmXc8wWI2PU8C5YMDSY qayt7oiWT7l6CyON7NWxV5LpVjJiERgmF1aBu2vmY6sY5xwX11Ql9YXSMlicGhtKc9otEcs+1Es+ w2/19SY/hMniWen3Qd3hny8nMiDI ----END CUT---- ----BEGIN RAW---- ERROR: 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:
----END RAW----

SQL query:

MySQL said: Documentation

#1064 - 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 '' at line 1

Jedynym problemem wydaje się, że moja strona indeksu brakuje treści, główną zawartość rzeczywiście. Wszystkie te pliki to .sql.

Następnie upuściłem wszystkie moje tabele i zaimportowałem oryginalną bazę danych z kwietnia ubiegłego roku. Oczywiście w tej bazie danych brakuje wszystkich informacji o koncie, informacji o zamówieniu itp. Dla wszystkich moich klientów, a także wszystkich zmian wprowadzonych w moich produktach.

Kiedy porównam dwie bazy danych, pierwsze 11 linii wydaje się być problemem, ale nie wiem, jak to naprawić. Pierwsze 11 wierszy pliku, który nie działa to:

-- 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"; 

pierwsze 11 linii pliku, który działa to:

-- 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"; 

I hve próbował po prostu skopiować i wkleić 11 wierszy z działającego pliku do pliku, który nie działa i pojawia się kolejny błąd.

Wiem, że to długa wiadomość i przepraszam, ale zmagam się z tym od wielu godzin i naprawdę potrzebuję pomocy.

Dzięki

Answer 1

OK, więc oto, co znalazłem, w końcu. Kiedy otworzyłem plik, który dawał mi błąd w notebooku +, ostatni wiersz, oczywiście, miał następujące:

ETXNULNULNULNULNULNULNULNULNUL

Oryginalny bazie roboczego po otwarciu nie ma żadnej z tych znaków.

Kiedy po prostu usunąłem ostatni wiersz pliku, który podawał mi błąd i zaimportował bazę danych, wszystko działało dobrze. Jednak moja strona główna nadal nie była prawidłowo podciągnięta. Zastosowałem na razie obejście i spróbuję to później zrozumieć.

Mam nadzieję, że to pomoże komuś.

Answer 2

Miałem ten sam problem podczas eksportowania mojej bazy danych dla witryny Joomla 2.5. Ma to coś wspólnego z kompresją w phpmyadmin. Zmieniłem kompresję z "none" na "zipped" przed eksportowaniem bazy danych i to rozwiązało.

Nadzieję, że pomaga!

Answer 3

Jest to błąd w phpMyAdmin

Oto tymczasowym rozwiązaniem

http://sourceforge.net/p/phpmyadmin/bugs/4095/#7e0c

lub coś w tym stylu:

zastąpić „PMA_Response :: getInstance() -> Wyłącz(); " "// PMA_Response :: getInstance() -> disable();" - /path_to_phpMyAdmin/export.php

Answer 4

Wygląda na to, że istnieje kilka powodów, które mogą wywołać ten błąd.Chciałem tylko podzielić się moim problemem i obejściem, jakie znalazłem w tym przypadku, mam nadzieję, że zaoszczędziłoby to komuś trochę czasu. Również napotkałem ten problem podczas próby zaimportowania bazy danych do MySql. Wyeksportowałem wersję bazy danych z mojego komputera lokalnego i chciałem ją zaimportować na serwer, na którym znajduje się moja witryna. Problem polegał na tym, że pomiędzy wersjami obu systemów występowało niedopasowanie. Udało mi się obejść problem za pomocą opcji zgodności (zarówno podczas eksportowania, jak i podczas importowania). użyłem "MYSQL323". To naprawiło mój problem. Myślę, że jest to dobre rozwiązanie dla tych, którzy mają możliwość wykonania nowej eksportowanej wersji bazy danych.

Answer 5

Naprawiłem ten błąd 1 minutę wcześniej. Po wyeksportowaniu pliku sql.gz spróbuj go rozpakować. Wyodrębniony plik jest nadal skompresowanym plikiem bu * .sql. Spróbuj dodać ponownie * .sql.gz I zaimportuj plik o zmienionej nazwie. to zadziała.

Co próbuję powiedzieć, że phpMyAdmin skompresuje plik dwukrotnie.

Answer 6

Moje rozwiązanie było: komentarz

;mbstring.func_overload = 2 

w /etc/php5/apache2/php.ini

Answer 7

W moim przypadku muszę zmienić kompresji NONE i kompatybilności SQL do trybu ANSI. Eksportowałem bazę danych WordPress na inny serwer.

Answer 8

Miałem ten sam problem z importowaniem pliku CSV i zorientowałem się, że problem polegał na tym, że miałem kilka pustych kolumn z konwersji Excela i kiedy wybrałem pierwszy wiersz jako nazwy kolumn do zaimportowania, próbowałem utworzyć kilka kolumn bez odpowiednich unikalna nazwa.

Answer 9

Miałem pusty wiersz na końcu pliku zrzutu. Usunięcie linii naprawiło mój problem.