Форум MySQL

Добрый день.
Помогите разобраться с параметрами утилиты.
Мне надо создать дамп одной таблицы, пишу такие параметры

mysqldump -u root -p1111 basename table --default-character-set=latin1 > table.sql

С полученым дампом не очень удобно работать, все записи с таблицы собраны в одной строке.
пример

INSERT INTO `auto_sell` VALUES (401,'TOYOTA','Corolla',2001,'','Бензин-инжектор','Универсал',''),(400,'TOYOTA','Corolla',2000,'','Бензин-инжектор','',''),(425,'Gaz','66',1996,'','','')..........

Какой добавить параметр, что бы каждая запись была в отдельной строке?
вот так

str  1   INSERT INTO `auto_sell` VALUES   2   (401,'TOYOTA','Corolla',2001,'','Бензин-инжектор','Универсал',''),  3   (400,'TOYOTA','Corolla',2000,'','Бензин-инжектор','',''),  4   (425,'Gaz','66',1996,'','',''), ...........................................................

Можно ли с помощью этой утилиты создать архив дампа? Текстовый файл получается большой и при импорте выдаёт ошибку 2006

можно отключить расширенные вставки -e=FALSE
и загнать пайпом весь вывод на вход какому нибудь архиватору. тому же zip / pkzipc / gzip
mysqldump ... | gzip ...

mysqldump --e=FALSE  -u testuser -ptestpwd test | gzip -c >res.zip

Спасибо за подсказку, по поводу многострочного insert помогло.
А вот с архивом ни как не могу справиться
Воспользовался Вашей подсказкой, но ни чего в архив не заносится, хотя сам архив создаётся. При этом пишет ошибку, что " ..."gzip" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом..."
писал так

mysqldump --e=FALSE  -u root -p1111 basename table | gzip -c >test.zip

Какие настройки надо проверить?

нужно найти утилиту gzip (gzip.exe) наверное?

по поводу того, какие настройки проверить, лучше промолчу.


oops. таки да. утилиту я указал несоответствующую расширению файла.
либо тип файла .gz и утилита gzip , либо тип файла .zip и утилита pkzipc либо zip .
не со зла, конечно. в каталоге с mysqldump'ом все три валялись - случайно промахнулся.

>по поводу того, какие настройки проверить, лучше промолчу.
почему?

а вот где лучше скачать саму утилиту?

потому что пары дней не проходит, чтоб кто-нибудь не написал.

Поставил ...A, B, C.
Написал D
Не работает.... ыыы .
Скажите почему, может какие настройки подкрутить у A или B?

Хочется ответить, "моск поставь, его же и подкрути". Но нельзя. Обидятся.


Где брать? В гугле. Аккуратно.
Можете в архиве, что я к посту прикрепил.

Благодарю за архив, всё работает, сам архивчик припрятал в укромное место :):):):)

а по поводу остального.... ну тут как посмотреть.

>а по поводу остального.... ну тут как посмотреть.

Вот вот. Как посмотреть.
Вот Ваше

mysqldump -u root -p1111 basename table --default-character-set=latin1 > table.sql INSERT INTO `auto_sell` VALUES (401,'TOYOTA','Corolla',2001,'','Бензин-инжектор',

Вот какой к богу в рай бензин-инжектор, если кодировка latin1 ?!!
Нету в latin1 ни единой русской буквы, не было никогда и не будет!

>Вот какой к богу в рай бензин-инжектор, если кодировка latin1 ?!!
я это понял с первого раза, как Вы мне это написали в другой теме.
Но всё это продолжение темы, которая находится здесь и ещё одной, в другой ветке формума.
По поводу дампа базы Вы мне писали:
"Самое честное решение - на php уровне вытащить все вытаскиваемые данные
(и возможно, тут же честно положить их в другую таблицу - корректно описанную, и через корректное подключение подцепленную)". Мне и самому приходила в голову такая мысль, Вы её подтвердили.
Так я и сделал, но результат меня не удовлетворил, почему, я писал здесь
Поискав ещё в инете, наткнулся на такую статью, вот в ней и описывается способ получения дампа, который нормально читается в редакторе, а для этого надо указать кодировку latin1.
Если этого не сделать, то в дампе ни чего нельзя будет прочитать, останутся теже крокозяблы, что и в самой базе.
Я исходил из того, что если в дампе нормально можно будет прочитать информацию, то это может повлиять положительно на результат.
Но, как показал эксперемент, отдельные символы не читаются всё равно. Это происходит после того, как я обрезаю информацию функцией substr() для превью, хотя если вывести польностью информацию, то всё отображается нормально.

>Так я и сделал, но результат меня не удовлетворил, почему, я писал здесь
Результат чего Вас не удовлетворил?
Перенос данных был выполнен вполне корректно.
А то что с utf-8 данными на php работать чуть сложнее, чем с однобайтовыми (что обычные строковые функции к ним неприменимы) - еще не повод откатываться на кривую версию базы.

>Поискав ещё в инете, наткнулся на такую статью

Так что залезать в статью о восстановлении данных было вроде как без надобности.

>, вот в ней и описывается способ получения дампа, который нормально читается в редакторе, а для этого надо указать кодировку latin1.

Я не смотрел эту статью.
Но полагаю, что если вы снимаете дамп на сервере с поддержкой кодировок (это версия 4.1 и выше) в кодировке latin1 , ТО в самом дампе (пусть даже внутри него текст будет вполне адекватным) в описаниях таблиц Вы получите всё ту же установку кодовой страницы в latin1, а значит фактически его потом будет не применить.
Снимать дамп в такой ситуации нужно в режиме совместимости со старыми версиями сервера (MYSQL 4.0) . И очевидно в этом случае в дампе никаких ремарок о типе кодировки оставлено не будет.

>Результат чего Вас не удовлетворил?

не удовлетворил потому, что после применения функции substr() последний символ обрезаной строки может выводится как "ромб, в нём ?". Хотя не всегда.

>что обычные строковые функции к ним неприменимы
спасибо за подсказку, пытаюсь разобраться с mb_***(), но пока что то не очень получается.

>Но полагаю, что если вы снимаете дамп на сервере с поддержкой кодировок (это версия 4.1 и
>выше) в кодировке latin1 , ТО в самом дампе (пусть даже внутри него текст будет вполне
>адекватным) в описаниях таблиц Вы получите всё ту же установку кодовой страницы в latin1, а
>значит фактически его потом будет не применить.

как раз в статье и говорится, что после снятия дампа надо изменить описание кодировки в самом дампе
цитата из статьи

В файле дампа поправляем операторы CREATE DATABASE и/или CREATE TABLE для создания таблиц в правильной кодировке. Либо меняем настройки database, как это было описано выше.

>>Результат чего Вас не удовлетворил?
>
>не удовлетворил потому, что после применения функции substr() последний символ обрезаной строки может выводится как "ромб, в нём ?". Хотя не всегда.

Я спросил не "почему", а "какого этапа" результат.
Каким боком это соотносится с выбранным методом?
Применяя подход из статьи Вы в конечном итоге столкнулись бы с тем же самым.
substr не будет работать с utf8 независимо от того, как именно это utf8 получено.

За цитату, рвущую страницу в горизонтальный скроллинг, отдельное луч поноса "мерси".

>Применяя подход из статьи Вы в конечном итоге столкнулись бы с тем же самым.
>substr не будет работать с utf8 независимо от того, как именно это utf8 получено.

Я испробовал все два способа, результат меня не удовлетворил, Вы сделали подсказку, у меня всё получилось (вроде). Пока смотрю, читаю, пробую на практике.....
Ещё раз благодарю.

>За цитату, рвущую страницу в горизонтальный скроллинг, отдельное ..... "мерси".

не знаю, почему у Вас что то не так с просмотром, но у меня всё нормально отображается. Если бы был горизонтальный скроллинг, то уж поверьте, я бы подправил....

подправляйте. :)

исправил :)

Ок. Мои рекомендации теперь можете воспринимать столь же образно :)

А меня такая запись не работает. Работает такая:

mysqldump -uLOGIN -pPASS DB | gzip >  /local_dir_DB.sql.gz

Ой, простите, что-то я устал уже...