Экспорт\Импорт столбца таблицы SQL

[D1m0n]

Подскажите как сделать экспорт одного столбца таблицы через phpmyadmin?

Есть 2 базы, которые были изначально одинаковые, но теперь в обоих изменения в разных столбцах. Если сделать иморт дампа одной в другую, то как я понимаю данные в базе-приемнике потеряются...

[Георгий]

а зачем через phpmyadmin
сделайте просто в mysql зайдя через консоль по ssh


ну в общем как через phpmyadmin - не знаю
а так вообще просто SQL-операторами можно сделать

[D1m0n]

Георгий, да в том то и дело, что в ssh я не силен...
З.Ы. Одна база на локальном компе (работает через Денвер), вторая на peterhost`e(помоему на моем тарифе ssh не дають :( )

[Георгий]

в phpmyadmin есть возможность выполнить SQL-скрипт
так что достаточно просто на локальном денвере сделать экспорт и залить этот SQL-файл на хостинг и выполнить через phpmyadmin

[at_hacker]

Заливать скрипты через PHPMyAdmin -- это реально парево Я вчера пол-дня пытался это сделать, потом плюнул и залил через утилю mysql. Проблема с кодировками. База в cp1251, скрипт -- в cp1251, при заливке выставляю "Кодировка файла" в cp1251, в базу же почему-то приезжает utf8. Зае... утомился, короче.

D1m0n, если тебе действительно нужен только одно поле перетащить, то только ручками. Выгружаешь данные из старой базы в формате, например, таком:

идентификатор_записи; значение_поля.

Затем пишешь скрипт, который будет генерить запросы типа

UPDATE table SET field_value="значение_поля" WHERE record_id=идентификатор_записи;

Ну, пачку этих запросов можно либо в отдельный файл сохранить, а затем попытаться выполнить в phpMyAdmin, либо написать скрипт так, чтобы он сам подключался к новой базе и данные там апдейтил.

[Silent]

at_hacker, я так подозреваю, что там у топикстартера ситуация ещё более жопная. Если он имеет две одинаковые по структуре БД, которые заполнялись параллельно на локальном и удалённом хостах, там будут записи с одинаковыми id но с разным содержимым полей. При этом он хочет сохранить все новые (отличающиеся) поля из обеих таблиц, но исключить дублирование строк (наличие идентичных записей). А теперь представь себе, что в обеих (локальной и удалённой) БД может быть несколько таблиц, в которых хранятся данные, привязанные к id редактируемой таблицы... Одним словом, не завидую. Если я правильно понял и изложил проблему, при этом обновить нужно десяток полей, это одно. А если пару тысяч...

ИМХО, чтобы дать готовый рецепт, нужно иметь в руках обе БД, при этом понимать, как взаимосвязаны между собой данные из отдельных таблиц внутри БД. Кроме того, нужно иметь время и большое желание со всем этим возиться.

[Георгий]

с кодировками проблемы решаются на этапе экспорта
если есть доступ по ssh, то указывая правильные ключики в запуске mysqldump можно получить экспорт в требуемой кодировке.
у меня подобная проблема была при переносе базы из MySQL4 в MySQL3.23. В 4-ой экспорт по дефолту делается в utf8, а в 3.23 надо latin1

[at_hacker]

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

Цитата(Silent @ 17.6.2008, 12:19) at_hacker, я так подозреваю, что там у топикстартера ситуация ещё более жопная. Если он имеет две одинаковые по структуре БД, которые заполнялись параллельно на локальном и удалённом хостах, там будут записи с одинаковыми id но с разным содержимым полей. При этом он хочет сохранить все новые (отличающиеся) поля из обеих таблиц, но исключить дублирование строк (наличие идентичных записей). А теперь представь себе, что в обеих (локальной и удалённой) БД может быть несколько таблиц, в которых хранятся данные, привязанные к id редактируемой таблицы... Одним словом, не завидую. Если я правильно понял и изложил проблему, при этом обновить нужно десяток полей, это одно. А если пару тысяч...

ИМХО, чтобы дать готовый рецепт, нужно иметь в руках обе БД, при этом понимать, как взаимосвязаны между собой данные из отдельных таблиц внутри БД. Кроме того, нужно иметь время и большое желание со всем этим возиться.

Вообще да, может быть, и так.

[D1m0n]

Silent, не совсем так... ситуевина какая. Скрипт инет-магазина. В одной базе менялись цены. В другой к этим же товарам привязывались картинки....

Вообщем проблемма сейчас другая...
Вообщем предистория... База была отдана человеку вместе с Денвером дабы изменить цены. При этом папку с пикчерзами товаров я не скопировал. Когда базу вернули то я тупо скопировал не ту папку с картинками и затеял панику, что записи о картинках потерлись. Имено поэтому и хотел выдрать записи о картинках из старой бызы и запихнуть в новую...
..так вот... сейчас оказалось, что с картинками на локальном хосте все нормально... но вот когда делаю дамп базы и заливаю на хостинг - то двиг сайта картинок не видит. :( Грешу на кодировку базы при переносе т.к. на локальном она 1251 а вот импортируется вроде utf-8

[Silent]

Цитата(D1m0n @ 20.6.2008, 16:53) двиг сайта картинок не видит. :( Грешу на кодировку базы при переносе т.к. на локальном она 1251 а вот импортируется вроде utf-8

Я бы ещё погрешил на неправильно написанные пути к картинкам. Может быть директорию с картинками залил на сервере не на тот уровень. Или вообще залить забыл =)))
Открой html-код страницы с удалённого сервера и посмотри, что написано фактически и что должно быть в реальности (пути к картинкам).
И сравни с html-кодом с локального хоста (где картинки есть).

[D1m0n]

Silent, не. я не на столько дилетант чтоб нитуда заливать.

[Silent]

D1m0n, зря ты обижаешься. Вопрос обычно не в дилетантизме, а в банальной ашипке. Человеку вообще свойственно ошибаться. Посмотри заодно права доступа на файлы картинок и директории, в которых они лежат. Ещё на глюкавых хостах бывает чехарда с владельцами файлов: залитые по ftp имеют одного владельца, а залитые скриптами - другого.

[at_hacker]

Ну, если у тебя в путях русские имена встречаются, то да, будут грабли с нахождением картинок из-за кривизны кодировок Но вообще-то это, мягко говоря, не очень распространённое поведение... А что, проверить, какой путь к картинке строится в скрипте и совпадает ли он с фактическим -- не судьба?

Про права доступа +1