Форум MySQL

Здравствуйте. При выполнении запроса:

INSERT INTO pages SET                 id_page = NULL,                 text = '',                 title = '1',                 id_cat = 7,                 descr = '1',                 keywords = '1',                 last_upd = NOW(),                 add_comments = 'no',                 id_lng = 1

Выдается ошибка

Column 'id_page' cannot be null

В чем может быть проблема.
Заранее спасибо за ответ.

первый раз вижу такой синтаксис.
обычно если INSERT, то VALUES
если SET, то UPDATE

Уже давно оценил выгоды такой записи:

1.Необязательно помнить порядок расположения столбцов в таблице. В такой записи столбцы не обязаны следовать друг за другом

2. Я сразу вижу что и куда у меня идет... Не надо угадывать по именам переменных или еще хуже вспоминать порядок следования столбцов, чтобы понять какое значение куда присваивается. Особенно, если запрос составлен был давно.

3. Удобно формировать запросы при помощи php:

<? $part = "descr = 'descr', "; $query = "INSERT INTO table SET                           id_page = NULL,                           title = 'title',"; $query .= $part; $query  .= "text = 'text'" ?>

4. Удобно переделать запрос на UPDATE

А совместимость со стандартами Вас не волнует?
Тогда извините, что вмешался.

Форма записи запроса не влияет... Глючит и другая форма: проверено.

Я просто, пользуясь случаем, делюсь своими нааблюдениями...

>А совместимость со стандартами Вас не волнует?
Разумеется она не волнует ни одного человека, который использует функцию mysql_query(), так как если речь идёт о совместимости со стандартном SQL, то необходимо пользоваться универсальным интерфейсом. Каждая программа оптимизируется по одному или нескольким параметрам: читабельность, краткость, скорость, переносимость, защита и т.д. и т.п. сосредоточиться сразу на всех параметрах невозможно. Если скрипт ориентируется на работу с базой данных MySQL, причём работать будет отсилы 1-2 года, зачем тратить усилия на гипотетическую совместимость со стандартом SQL, тем более добиться её всё равно не реально пока на MySQL.

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

Вы же не предлагаете такой диалект ни в учебниках, ни в собственных примерах?
Хотя он и впрямь аккуратнее выглядит? Почему?

Мы об нём упоминаем, однако в стандарт он не попал не просто так, он действительно немного не удобен... стандарный вариант естественно расширяется до многострокового значения, вариант с SET - нет. При помощи стандартного варианта можно также не заполнять поля - поэтому дублирование синтаксиса тут выглядит как неортогональность диалекта. Тут я больше с вами соглашусь, я лишь хотел подчеркнуть, что в SQL стандарт очень здорово от реальности отстаёт - на несколько лет и придерживаться его практически не реально, особенно в MySQL, которая долгое время имела крайне своеобразный SQL.

PS Мне собственно ваш обвинительный тон не понравился :))), ну использует разработчик не стандартную фичу конкретной СУБД - что в этом плохого, хранимые процедуры в MS SQL тоже были долгое время не стандартной фичей...

Используется:

MySQL client version: 4.0.24

Таблица pages определяется так:

CREATE TABLE pages (   `id_page` INT(32) NOT NULL AUTO_INCREMENT,   `text`  MEDIUMTEXT,   `title` TINYTEXT,   `id_cat` INT,   `descr`  MEDIUMTEXT,   `keywords`  MEDIUMTEXT,   `last_upd` TIMESTAMP,   `add_comments` ENUM('yes', 'no'),   `id_lng` INT,   PRIMARY KEY(`id_page`) );

Нет здесь ничего крамольного?

А так:

INSERT INTO pages SET                  id_page = 'NULL',                  text = '',                  title = '1',                  id_cat = 7,                  descr = '1',                  keywords = '1',                  last_upd = NOW(),                  add_comments = 'no',                  id_lng = 1

тоже не проходит?

`id_page` INT(32)
что-то мне подсказывает, что такие огромные числа MySQL хранить просто не умеет.
Хотя... надо глянуть в мануал.

---
Собственно 32 ничем не хуже и не лучше 255. Это всего лишь ширина поля. Величины же будут где-то в районе 10 знаков.

Это число номинально, на количество памяти только тип INT влияет, у столбца id_page никогда не будет больше 11 позиций, хотя можно написать вместо 32 хоть 100 - это поле используется лишь при форматном выводе.

При консольном выводе?
Я-то это понимаю.
Только в php характеристики ширины столбца таблицы читают в одном случае из тысячи. Да и тот - phpMyAdmin.
Просто когда такое число как 32 попадается в скобках после INT, это почти наверняка значит, что написавший его хотел выразить совсем другую вещь.

Вообще уберите

id_page = NULL,

id_page у вас точно автоинкрементное?

Да, как видите :)

Оказалось, что при установке дампа столбцам первичного ключа не было присвоен атрибут auto_increment. Вот отрывок из дампа: что тут криминального ? :)

CREATE TABLE `pages` (   `id_page` int(32) NOT NULL,   `text` mediumtext,   `title` tinytext,   `id_cat` int(11) default NULL,   `descr` mediumtext,   `keywords` mediumtext,   `last_upd` timestamp NOT NULL,   `add_comments` enum('yes','no') default NULL,   `id_lng` int(11) default NULL,   PRIMARY KEY  (`id_page`) ) TYPE=MyISAM AUTO_INCREMENT=39 ;

Только то, что Вы и написали. У поля Не стоял признак автоинкремента:

CREATE TABLE `pages` (    `id_page` int(32) NOT NULL auto_increment,    `text` mediumtext,

Он стоит, но стоит своеобразно. Я бы тоже написал также, как и вы, но phpmyadmin при создании дампа разместил это здесь:

add_comments` enum('yes','no') default NULL,   `id_lng` int(11) default NULL,   PRIMARY KEY  (`id_page`) ) TYPE=MyISAM AUTO_INCREMENT=39 ;

Значит дамп был создан некорректно. Или в исходной таблице поле потеряло это свойство.

это разные вещи.
Одно дело - текущее значение инкремента.
Другое - описание поля.
Если поле не описано, как сервер узнает, что именно оно является наращиваемым?

Я уже когда-то поднимал тему о несовместимости дампов. Можно ли как-то управлять созданием дампа, ислючая несовместимые конструкции? Особенно некоторые версии mysql не любят указание кодировки при создании таблицы.
Правильно ли мое наблюдение: на локалке, если нет особой надобности, лучше установить версию mysql ниже, чем на хостинге. Тогда дампы будут 100% совместимы?

Можно, при помощи утилиты mysqldump можно не только создавать дампы для страых версий MySQL, но и для других СУБД. Для этого используется параметр --compatible, который может принимать значения ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb и т.д.

PS Только использовать mysqldump на хостинге не всегда возможно.

Главное на localhost можно. Некоторые пользователи Proteus присылают мне такие дампы. Мне приходится править их вручную...

Не работает. Что-то не так?

C:\server\usr\mysql\bin>mysqldump -u root --compatible ansi proteus > proteus.sql

Нужно так:

C:\server\usr\mysql\bin>mysqldump -u root --compatible=ansi proteus > proteus.sql

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

unknown variable 'compatible=mssql'

В смысле, не очень понятно, что имеется ввиду?

Поправил предыд. пост

/* Поглядывая в мануал */ Дело в том, что эта опция доступна только начиная с MySQL 4.1...

Установил mysql50 - получается. Вот только кириллица в дампе заменяется на знаки вопроса. Можно ли как-то поправить кодировку?

А вы кодировку настраивали? Пропишите в my.ini в секции [mysqldupm] строку

default-character-set=cp1251

А лучше сразу пропишите в секции [mysqld], тогда и mysqldump кодировку от туда подцеплять будет.

1) В секции mysqld кодировка прописана, но на результат это не влияет.
2) Если прописать кодировку в секцию [mysqldump] :

[mysqld] port=3306 basedir="C:/server/usr/mysql" datadir="C:/server/usr/mysql/Data" default-character-set=cp1251 [mysqldump] default-character-set=cp1251

Вылезет вот что:

mysqldump: Character set 'cp1251' is not a compiled character set and is not specified in the 'C:\mysql\\share\charsets\Index.xml' file