2011-05-04 12 views
9

Komut satırı üzerinden mysqldump dosyasını almaya çalışıyorum, ancak bir hata almaya devam ediyorum. SonraMysql ERROR satır 1153: Bilinmeyen komut ''

mysql -u XXX -p database_name < database.sql 

Bu küçük bir bölümünü yükler ve takılıyor:

mysqldump -u XXX -p database_name > database.sql 

Sonra dosyayı almayı deneyin: Ben kullanarak benim diğer sunucudan dosya bırakmıştı. Aldığım hatadır:

ERROR at line 1153: Unknown command '\''. 

Birlikte dosyada o satırı işaretli:

awk '{ if (NR==1153) print $0 }' database.sql >> line1153.sql 

ve sadece o satır için, 1 MB boyutundaki üzerinde olur.

Burada neler olabileceği hakkında bir fikrin var mı?

cevap

17

DB'nizde ikili lekeler var, mysqldump deyiminize --hex-blob eklemeyi deneyin.

+1

Bu işe yaradı! Çok teşekkürler. – Chris

+2

Aynı problem var ama --hex-blob çalışmıyor. başka bir çözüm mü? thx – Jon

3

Sen neler olduğunu biliyoruz! - Eğer SQL ekstra tek alıntı Ey

kolaylığı ile line1153.sql dosyasını açacak 'awk', muhtemelen 'vi' olan varsa

ve Veritabanınızdaki soruna neden olan değeri bulmanızı sağlar.

Veya ... Birden çok satır içerdiğinden satır büyük olabilir. Ayrıca, her satırın ayrı bir ekleme ifadesi alması için --skip-extended-insert seçeneğini mysqldump'a da kullanabilirsiniz.

İyi şanslar.

2

Aynı sorun vardı çünkü veritabanımda Çince karakterler vardı. Aşağıda bazı Çin forumlarından buldum ve benim için çalıştı.

mysql -u[USERNAME] -p[PASSWORD] --default-character-set=latin1 
[DATABASE_NAME] < [BACKUP_SQL_FILE.sql] 
0

Diğer her şey başarısız olursa, içe aktarma işlemini yapmak için MySQLWorkbench'i kullanın. Bu benim için aynı sorunu çözdü.

1

Sana Ayrıca database < path/to/file.sql nedense benim için işe yaramadı yerine path\to\file.sql

ait path/to/file.sql kullanmaya ihtiyacım var - Ben use database; ve source path/to/file.sql; kullanmak zorunda kaldı.

+0

Bu cevaba dayanarak yapılan testler, bunun beni şaşkına çeviren MySQL CLI'nin Windows yüklemesinde d: \ path \ to \ file.sql kullandığımda ortaya çıkan bir dizi hata mesajının kaynağı olduğunu onaylıyor. Bir çıkış yolunu belirleyen bir tee komutunda bile göründüğü için. Bir Windows yüklemesinde CLI'de belirtilen herhangi bir yol için aynı beklemelerden şüpheleniyorum. –

0

Son zamanlarda, bir Windows makinesinde bir sql dökümü yaptığım ve bir Linux makinesinde yüklemeye çalıştığım benzer bir sorunla karşılaştım. Ben noktaya tüm metni kopyalamak için aşağıdaki komutu kullanılır Oldukça büyük bir SQL dosyasını vardı ve benim hata hattı 3455360. oluyordu Hatayla nerede:

sed -n '1, 3455359p' < sourcefile.sql > destinationfile.sql

Bu kopyalanan tüm iyi kod içine bir hedef dosya. Hedef dosyanın son birkaç satırına baktım ve tam bir SQL komutu olduğunu gördüm (Son satır bir ';' ile bitti), böylece iyi kodu aldım ve herhangi bir hata almadım. Daha sonra 20 satır olan dosyanın geri kalanına baktım.Bu kod sonuna aşağıdaki php kodu gördü c/ihracat b tamamlamış olmayabilir çıkıyor:

Array 
(
    [type] => 1 
    [message] => Maximum execution time of 300 seconds exceeded 
    [file] => C:\xampp\htdocs\openemr\phpmyadmin\libraries\Util.class.php 
    [line] => 296 
) 

Ben kusurlu php kodu kaldırıldı ve veritabanının kalanını ithal.

0

_\ gibi tablo adlarında özel bir karakter vardı ve bu tabloları almaya çalışırken hata veriyor. değiştirilerek, \\, dumped sql olarak değiştirildi. ben bu komutu kullanılır rate_\ gibi ve benim masa isimleri dökümü onarmak için: cümledeki olmamalıdır veritabanında yerde bazı ters eğik çizgi varsa ben emin değildi çünkü,

sed 's._\\._\\\\.g' dump.sql > dump2.sql 

i tüm ters eğik çizgi yerine.

Tablo adındaki özel karakterler dosya adında @ işaretine dönüştürülecektir. oku oku http://dev.mysql.com/doc/refman/5.5/en/identifier-mapping.html

İlgili konular