Форум MySQL

Здраствуйте еще раз! В прошлый раз вы мне очень помогли... К сожадению, аськи cheops'а и других умных людей с форума не имею, почему и пишу сюда. Вопросы состоят вот в чем. Первый, самы дурацкий. На удаленном хосте сделал дамп бд с параметром "INSERT" для того, чтобы тут, на лок хосте эту бд себе поднять. В общем делаю так:

"Месторасположение текстового файла:"
ввожу "C:\\smart.sql" жму "Вперед". Пхпадмин ругается, что "Нет SQL-запроса!", хотя он есть, и раньше так работало. Вот начало sql файла:

-- phpMyAdmin SQL Dump -- version 2.8.0.3 -- http://www.phpmyadmin.net --  -- Хост: localhost -- Время создания: Май 08 2007 г., 19:04 -- Версия сервера: 4.1.18 -- Версия PHP: 4.4.2 --  -- БД: `smart` --  -- -------------------------------------------------------- --  -- Структура таблицы `content` --  CREATE TABLE `content` (   `id` int(11) NOT NULL auto_increment,   `id_topic` int(11) NOT NULL default '0',   `avtor` mediumtext,   `text` text,   `ip` mediumtext NOT NULL,   `date` datetime NOT NULL default '0000-00-00 00:00:00',   `id_avtor` int(11) NOT NULL default '0',   PRIMARY KEY  (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=62865 ; --  -- Дамп данных таблицы `content` --

и так далее. Т.е. запрос реально есть. Файл весит 4.92 мб.

Вопрос второй. Есть у меня в разных тэблах куча полей с типами DATETIME. Мне так с ними работать неудобно, поэтому я их хочу перегнать в секунды. Но подстава в том, что с помощью такого скрипта:

<?php     include("config.php");          $query = "SELECT * FROM smart_users";     $result = mysql_query($query);          while($row = mysql_fetch_object($result)) {              $query = sprintf("UPDATE smart_users SET date = '%s' WHERE id = %d", strtotime($row->date), $row->id);         $resulted_query2 = mysql_query($query);            } ?>

Почему то в результате вижу во всех полях "00-00-00 00:00:00" вместо ожидаемых секунд. Итак, как мне рациональнее и в какой момент времени работы скрипта тип поля изменить и как это сделать. Заранее спасибо за помощь, жду.

1.
>В общем делаю так:
>"Месторасположение текстового файла:"
непонятно

2. Эти преобразования можно сделать тремя операторами SQL прямо в PMA:

из строк в секунды

ALTER TABLE `tab` CHANGE `fld` `fld` CHAR( 20 ) NOT NULL DEFAULT '0000-00-00 00:00:00'; UPDATE tab SET fld = UNIX_TIMESTAMP(fld); ALTER TABLE `tab` CHANGE `fld` `fld` INT(11)  NOT NULL DEFAULT '0';

из секунд в строки

ALTER TABLE `tab` CHANGE `fld` `fld` CHAR( 20 ) NOT NULL DEFAULT '0000-00-00 00:00:00'; UPDATE tab set fld = FROM_UNIXTIME(fld); ALTER TABLE `tab` CHANGE `fld` `fld` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00';

Trianon, по тому, что ты написал, форматированнная дата сама средствами пхпадмина станет секундой?

По поводу запуска дампа - там можно код ввести и можно выбрать файл с sql запросом. Так как запрос слишком большой (5 мб) я выбираю "Месторасположение текстового файла:" и пишу путь к моему .sql дамп-файлу. Он думает и пишет, что там нет SQL запроса.

1. То что я написал имеет смысл понять. Там не так сложно.
Но в целом, если под секундой (кстати, почему одной?) понимается таймштамп unix, то да. станет.


2. а в php умалчиваемое двухмегабайтовое ограничение на загрузку файлов на сервер дядя снимать будет?

1. Имелся ввиду формат "секунда", ну, правильнее говоря, тот самый unix timestamp. Спасибо :)
2. Раньше я так запускал 3.5 мегабайтные запросы из файла (форум не так разросся) и ничего. Что мне делать в конкретной ситуации?

Ребят, по второму вопросу очень нужно решение проблемы!!! Жду. Завтра проект сдавать.

pma работает с упакованными дамп-файлами, насколько мне известно.
в формате zip и gz.
Попробуйте запаковать дамп.

Trianon, ОГРОМНЕЙШЕЕ тебе спасибо, с gz прокатило! УРА! Не могу понять, чем ему .sql не понравился. Еще раз спасибо! Сейчас буду меня ть поля :)

Блин, сделал как вы сказали, а вместо текста во всех полях кракозябры :( Такого раньше не было.

Это совершенно не зависит от формата обертки.
Кракозябры - признак проблем с кодировками.

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

В начало дампа имеет смысл поставить оператор
SET NAMES 'cp1251';
если конечно сам дамп у Вас снят именно в этой кодировке.
И если сам дамп - корректный (т.е. содержит неискаженные данные). Иначе надо разбираться уже по ситуации.

После этого таблицы удалить, а дамп перезалить заново.


Кроме того Вы не сказали - где и как именно Вы наблюдаете кракозябры.
И какие именно.

Кодровку надо устанавливать именно этим запросом в начале каждого сеанса работы с MySQL

Вижу в поле текст "РЇ страдал РЅРµ€РґР°РІРЅРѕ, потом РЅР°Р..." вместо "Я страдал недавно, потом надоело. Не без гордости ..."

Я правильно понял - в .sql файле нужно прописать "SET NAMES 'cp1251';" ? Такая строчка у меня прописана в config.php, где ведется подключение к бд

З.Ы.: открываю в блокноте весь дамп - кодировка нормальная, кроме того я заметил, что у меня написано:

CREATE TABLE `content` (   `id` int(11) NOT NULL auto_increment,   `id_topic` int(11) NOT NULL default '0',   `avtor` mediumtext,   `text` text,   `ip` mediumtext NOT NULL,   `date` datetime NOT NULL default '0000-00-00 00:00:00',   `id_avtor` int(11) NOT NULL default '0',   PRIMARY KEY  (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=62865 ;

Текст такого вида - явный признак того, что дамп у Вас в формате utf8.
Соответственно и оператор установки кодировки в начале дампа должен быть SET NAMES 'utf8'
А какая кодировка у Вас применяется в скрипте - Вы не сказали.
Если 1251 - то всё правильно.

По поводу конвертации строк в секунды - спасибо, все сработало, один только вопрос, почему выходной ти поля INT(11), а не TIMESTAMP? Будет ли достаточно INT(11) в дальнейшем? Может лучше для этого использовать тип TEXT? Что рациональней в смысле быстродействия и юзабилити?

поле TIMESTAMP (как ни странно)будет требовать при вводе и возвращать при выводе данные точно также как и поле DATETIME - можете проверить сами. Разница между ними в основном во внутреннем представлении данных, да еще в том, что TIMESTAMP можно сделать автоматически следящим за операциями внесения изменений в строки таблицы. Так что если хотите лицезреть именно число секунд - пользуйтесь INT.

Если хочется автоматом отслеживать время изменения строк - нужно TIMESTAMP
В смысле легкости администрирования рациональнее DATETIME и TIMESTAMP
Если нужно работать с данными до 1970 или после 2034 года - то только DATETIME
Если требуется максимальная портабельность между базами данных - подойдет только INT
Выбор за программистом.

Все понял. В скрипте config.php прописано

mysql_query("SET NAMES cp1251");

А в дампе ничего нет. Короче я запутался :(

Вопрос, после 2034 года уже нельзя будет пользоваться time() в пхп что ли?

На самом деле до конца 2037 (еще точнее - до 19 января 1938)
Ограничение это связано с размером типа long ( а в php - int) .
Наверняка, куда раньше чем к 30-м годам подавляющее большинство компьютеров будут 64-битными и такое ограничение отпадет само собой.

Будем надеяться :) Вобщем я понял, я до этого делал дамп всех таблиц, а сейчас попробовал сделать дамп базы. Потом файл импортнул в пма. Он его скушал, поблагодарил, а база не появилась xD

Веселуха :)

Вобщем ерунда полная!

На запрос

CREATE TABLE `content` (   `id` int(11) NOT NULL auto_increment,   `id_topic` int(11) NOT NULL default '0',   `avtor` mediumtext,   `text` text,   `ip` mediumtext NOT NULL,   `date` datetime NOT NULL default '0000-00-00 00:00:00',   `id_avtor` int(11) NOT NULL default '0',   PRIMARY KEY  (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=62865;

мне пишется

Возможно у Вас ошибка в SQL-парсере. Пожалуйста, проверьте внимательно Ваш запрос и соответствие кавычек. Возможно также, что Вы пытаетесь закачать бинарный файл вне поля quoted text area. Вы можете попробовать выполнить свой запрос через интерфейс командной строки MySQL. Описание ошибки MySQL сервера дано ниже, возможно оно поможет понять, что же произошло. Если у Вас все равно возникают проблемы или если парсер выдает ошибки там, где интерфейс командной строки работает успешно, попробуйте изменить свой SQL запрос до простых запросов и определить, какой именно вызывает проблемы. Вы можете также прислать отчет об ошибке вместе с блоком данных (секция CUT):
----BEGIN CUT----
eNpzDQryD7JScDZUcDZS8HH1s1IwUjBWMDX jCg4BCjNzcTmHBVspqHimWCkUF+YUJBYVpxbp5WQm
6RVkFOiUKRjpGZkrGBkYmOgbGuobmCoYGFi ZGFqZmirkpOZaKrhWFCiocPlWBgf6WCmY6B nqGZrp
5iZWcIUGByn4B+soOLq7+oXoKIS5Aq0Kz8xT8A9wDXJUsNQzMOIK8HUE OkXPTM+QK8AjAKRExx/o
EFOgIWYK4Z5+fiFcPo5+7lYKRaW65Zl5hkamhlxgawK8mVlEGBgYOBg W1q000/m1b/WRV5IMq/b6
MXABRXPykxNzMvKLS/SAvllSm10tfXzqs/L/XY82AwCpokoI
----END CUT----
----BEGIN RAW----
ERROR: C1 C2 LEN: 2 3 56
STR: 

CVS: $Id: sqlparser.lib.php,v 2.27 2004/11/05 00:41:55 lem9 Exp $
MySQL: 4.1.16-max
USR OS, AGENT, VER: Win OPERA 9.02
PMA: 2.6.1
PHP VER,OS: 5.1.6 WINNT
LANG: ru-win1251
SQL: PK


Бред какой-то.

З.Ы. Это может как-нибудь быть связано с настройками апача? Или с тем, что на удаленном хосте и на лок хосте разные версии пхп?

Хехе :) Вобщем, если кому интересно, мне так и не удалось заимпортировать базу данных из файла, пришлось все делать вручную. ПМА - зло. Нкогда еще он у меня так не глючил.

Ну вот, мне получилось импортнуть всю базу. И опять кракозябры.

Судя по SQL: PK Вы либо перепутали gz и PKZIP, либо забыли указать правильный формат компрессора.

Учиться работать с PMA лучше на дампах покороче и эксперементируя на собственной машине.

Спасибо... Но я напомню, мне удалось базу данных импортнуть, но кодировка... Понимаете, раньше не имея практически никаких знаний я просто экспортировал все таблицы и импортировал их в локальную базу - все было без проблем, не было никаких неприятностей, ни с кодировкой, ни с SQL запросом... Я не могу понять, в чем дело. Если я переустановлю denwer это как то мне поможет? Проблема на данный момент заключается в том, что я не хочу переустанавливать его, т.к. тут мне мой начальник сделал какие-то дополнительные настройки апача, о которых я не знаю и сохранить их после переустановки локального сервера я не смогу.

сомневаюсь, что переустановка денвера что-то даст.
Правила, влияющие на ситуацию, я Вам описал.
Кодировка текста в дампе должна соответствовать кодировке соединения клиент-сервер на момент загрузки дампа.
Кодировка соединения клиент-сервер и кодировка результатов запроса при работе с базой из собственных скриптов должна соответствовать кодировке HTML-страниц самих скриптов.
Кодировка данных в самой таблице должна соответствовать объявлению в свойствах таблицы.

Других правил нет. Другие знания не влияют на ситуацию к кракозябами.

Я понимаю, что это выглядит глупо, но не могли бы вы мне конкретно расписать алгоритм корректной перезаливки бд? Прям по пунктам, вплоть до того где и как указывать кодировку. Туплю я. Ну или дайте линк на русский ман по пма...