Operation violates check constraint INTEG_6

@aarumyan15267 · Регистрация: 23.03.2013

Author24 — интернет-сервис помощи студентам

Привет всем ввожу в IBquery следующий код:

SQL

1	INSERT INTO OBSH_SVED (FIO, NOM_SPEC, NAZ_GR, KVAL, TELEFON, PHOTO, NOM_ZACH, PASSWORD_ST ) VALUES (:FIO, :NOM_SPEC, :NAZ_GR, :KVAL, :TELEFON, :PHOTO, :NOM_ZACH, :PASSWORD_ST);

При попытке активации Query вылезает ошибка Operation violates check constraint INTEG_6...
Скрипт таблицы:

SQL

CREATE TABLE obsh_sved (
FIO VARCHAR (20),
Nom_spec VARCHAR(7) CHECK (Nom_spec>0),
Naz_gr VARCHAR (6),
Kval VARCHAR (20),
Telefon VARCHAR(12) CHECK (Telefon>0),
Photo BLOB,
Nom_zach VARCHAR(7) NOT NULL CHECK (Nom_zach>0) PRIMARY KEY,
Password_st VARCHAR (12),
FOREIGN KEY (nom_spec) REFERENCES Spec ON UPDATE cascade,
FOREIGN KEY (naz_gr) REFERENCES Gruppa ON UPDATE cascade);

Все действия проводятся в Interbase 6.5! Удаляю CHECK везде и все получается. В чем может быть дело?
И еще вопрос, если не трудно проблема с вводом информации в поле NOT NULL. Ошибка Validation error for column Nom_zach, value "*** null ***".

Скандербег · 11.10.2014, 09:18

Как выглядит "активация Query"?

А дело в том, что не надо заставлять сервер СУБД делать проверку отправляемых данных, не зная что делать с его ответами при получении им "мусорных" данных.
Проще и предсказуемо проверять введенные данные в клиентском приложении. В нем можно и по рукам юзеру дать, если не так ввел.
В этом случае в базу отправятся заведомо корректные данные и не будут от сервера приходить ошибки.

если не трудно проблема с вводом информации в поле NOT NULL

Не трудно, но проблема при вводе в чем?
Требование NOT NULL говорит всего лишь о том, что при записи и обновлении данные для этого поля должны быть.
Если их нет, то и получаем ошибку.

Не по теме:

А зачем эти внешние ключи? Отчет себе отдаете для чего они нужны?

@xxbesoxx · 11.10.2014, 11:09

Сообщение от aarumyan15267

FOREIGN KEY (nom_spec) REFERENCES Spec ON UPDATE cascade, FOREIGN KEY (naz_gr) REFERENCES Gruppa ON UPDATE cascade);

Вот здесь у вас (nom_spec и naz_gr) внешний ключ ! связан на таблице REFERENCES Spec и на каком поля он ссылается ?
А инсерте он должен брать значения из таблиц Spec но из какой поля неизвестно на ваши коде . почитайте учебнике для чего создается (Primary и Foreign Key)

@aarumyan15267 · 11.10.2014, 13:01 **[ТС]**

Для чего создаются ключи я знаю) Таблица "общие сведения" связывается с таблицами "специальность" и "группа"

SQL

1 2	CREATE TABLE Spec ( Nom_spec VARCHAR (7) NOT NULL CHECK (Nom_spec>0) PRIMARY KEY);

SQL

1 2	CREATE TABLE Gruppa ( Naz_gr VARCHAR (6) NOT NULL PRIMARY KEY);

Добавлено через 11 минут
Просто дело в том, что я бы не делал эти таблицы, если не курсач и не советы "Препода"
Если поле "NOT NULL PRIMARY KEY" программа выводит Validation error for column Nom_zach, value "*** null ***"
Короче понял что номером зачетки связывать это бред, т.к надо чтобы одному студенту могли принадлежать несколько записей в таблице "вложения". И как я понял Нужно создать столбец id_studenta и сделать его автоинкрементным и связать таблицы по нему? То есть как я понял чеки лучше вообще убрать. А с инсертом то что делать?

Добавлено через 5 минут
И есть ли вообще автоинкрементные поля в ibconsole?

Скандербег · 11.10.2014, 14:56

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

Да, ibconsole здесь вообще ни при чем.
В СУБД IB есть генераторы и триггеры, которые и позволяют устраивать автоинкрементные поля-идентификаторы.

Внешние ключи, как показаны в приведенном примере, не нужны - они просто ничего не будут делать.
Если и создавать FK то для подчиненных таблиц, например, для каскадного удаления.
Это когда нужно автоматом удалить данные из таблиц, связанных с главной, когда из нее удаляется запись.
Впрочем, здесь внешние ключи на таблицы специальности и группы тоже создавать нельзя, т.к. это не подчиненные таблицы.
Так что забудем про FK, до тех пор пока не придет осознание для чего они нужны и в каких случаях создаются.

У таблиц Специальности и Группы должно быть автоинкрементное поле-идентификатор с уникальным значением для каждой строки.
В таблице "общие сведения", нужно создать поля, в которые бы записывались значения поля-идентификатора из упомянутых таблиц.
Одно такое поле есть - Nom_spec. Но тип его должен быть Integer. В него и нужно записывать ИД специальности.
Так же и с полем, в которое нужно записывать значение идентификатора из таблицы Группы.

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

@aarumyan15267 · 12.10.2014, 22:23 **[ТС]**

Сообщение от Скандербег

Так что забудем про FK, до тех пор пока не придет осознание для чего они нужны и в каких случаях создаются.

Так вот не могу забыть( У меня Таблица "Общие сведения" должна быть связана с таблицей "Вложения" по полю ID_STUD, то есть каждому студенту принадлежат несколько вложений)

Скандербег · 12.10.2014, 22:39

Судя по объявлению внешних ключей у вас несколько превратное представление о действии связей по внешним ключам между таблицами.
Связи между таблицами могут быть физическими по FK для определенных целей (пример выше был приведен) и логическими, по уникальным идентификаторам совсем для других целей (для объединения данных из нескольких таблиц при выборке, например). Видимо, преподаватели еще не донесли до вас такую дифференциацию связей таблиц в базах данных.
Именно эти логические связи и спасут вашу работу. А FK здесь вообще ни при чем.
В этом вопросе пока виден полный раздрай и не понимание. Поэтому и было рекомендовано убрать FK. Чтобы не мешали записывать данные.

@aarumyan15267 · 13.10.2014, 00:29 **[ТС]**

Сообщение от Скандербег

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

Извините, но как сделать эти самые логические связи?

Скандербег · 13.10.2014, 07:30

Логические связи на примере таблиц Студенты и Группы.
В таблице Группы должно быть поле уникального идентификатора строк (назовем его ID - тип Integer).
Т.е. каждая запись в этой таблице как бы "маркируется" своим числом.
В таблице Студенты есть поле ID_GROUP тоже типа Integer.
При записи в таблицу данных о студенте в поле ID_GROUP записывается значение ID из таблицы Группы.
Так получаем связь между студентом и нужной группой. FK здесь лишний.
В этом и вся логическая связь.
При выборке данных по студенту в запросе пишется объединение данных (JOIN) чтобы вместо идентификатора из поля ID_GROUP в программе можно было показать название группы. Про объединения надо читать, здесь не расскажешь.

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

Что касается таблиц "Общие сведения" и "Вложения", которые должны быть связаны по полю ID_STUD.
Если записи в таблице Вложения должны быть гарантировано удалены при удалении соответствующей записи из таблицы "Общие сведения" (и только в этом случае), то FK создается в таблице Вложения на поле ID_STUD на каскадное УДАЛЕНИЕ ее записей (но не на UPDATE) и ссылающийся на первичный ключ в таблице "Общие сведения" (уник. идентификатор, назовем его тоже ID), .
Но и для такого FK есть альтернатива в виде удаления логически связанных (по полям ID_STUD и ID) записей из т. "Вложения" перед удалением соответствующей записи из т. "Общие сведения", которое делается в клиентской программе.

Не по теме:

Для более удобного манипулирования базой данных вместо IBConsole лучше использовать IBExpert.

Скандербег 1074 / 987 / 340 Регистрация: 07.08.2012 Сообщений: 2,790
	11.10.2014, 09:18	2
	Как выглядит "активация Query"? А дело в том, что не надо заставлять сервер СУБД делать проверку отправляемых данных, не зная что делать с его ответами при получении им "мусорных" данных. Проще и предсказуемо проверять введенные данные в клиентском приложении. В нем можно и по рукам юзеру дать, если не так ввел. В этом случае в базу отправятся заведомо корректные данные и не будут от сервера приходить ошибки. если не трудно проблема с вводом информации в поле NOT NULL Не трудно, но проблема при вводе в чем? Требование NOT NULL говорит всего лишь о том, что при записи и обновлении данные для этого поля должны быть. Если их нет, то и получаем ошибку. Не по теме: А зачем эти внешние ключи? Отчет себе отдаете для чего они нужны? 0

@xxbesoxx 1134 / 615 / 129 Регистрация: 13.02.2009 Сообщений: 3,553
	11.10.2014, 11:09	3
	Сообщение от aarumyan15267 FOREIGN KEY (nom_spec) REFERENCES Spec ON UPDATE cascade, FOREIGN KEY (naz_gr) REFERENCES Gruppa ON UPDATE cascade); Вот здесь у вас (nom_spec и naz_gr) внешний ключ ! связан на таблице REFERENCES Spec и на каком поля он ссылается ? А инсерте он должен брать значения из таблиц Spec но из какой поля неизвестно на ваши коде . почитайте учебнике для чего создается (Primary и Foreign Key) 0

Скандербег 1074 / 987 / 340 Регистрация: 07.08.2012 Сообщений: 2,790
	11.10.2014, 14:56	5
	Проверку на корректность данных лучше, конечно делать в программе, а из таблицы проверки убрать. Да, ibconsole здесь вообще ни при чем. В СУБД IB есть генераторы и триггеры, которые и позволяют устраивать автоинкрементные поля-идентификаторы. Внешние ключи, как показаны в приведенном примере, не нужны - они просто ничего не будут делать. Если и создавать FK то для подчиненных таблиц, например, для каскадного удаления. Это когда нужно автоматом удалить данные из таблиц, связанных с главной, когда из нее удаляется запись. Впрочем, здесь внешние ключи на таблицы специальности и группы тоже создавать нельзя, т.к. это не подчиненные таблицы. Так что забудем про FK, до тех пор пока не придет осознание для чего они нужны и в каких случаях создаются. У таблиц Специальности и Группы должно быть автоинкрементное поле-идентификатор с уникальным значением для каждой строки. В таблице "общие сведения", нужно создать поля, в которые бы записывались значения поля-идентификатора из упомянутых таблиц. Одно такое поле есть - Nom_spec. Но тип его должен быть Integer. В него и нужно записывать ИД специальности. Так же и с полем, в которое нужно записывать значение идентификатора из таблицы Группы. Если убрать чеки полей и внешние ключи, то INSERT должен отработать нормально, если, конечно, запрос и записываемые значения в нем корректны. 0

@aarumyan15267 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 96
	12.10.2014, 22:23 [ТС]	6
	Сообщение от Скандербег Так что забудем про FK, до тех пор пока не придет осознание для чего они нужны и в каких случаях создаются. Так вот не могу забыть( У меня Таблица "Общие сведения" должна быть связана с таблицей "Вложения" по полю ID_STUD, то есть каждому студенту принадлежат несколько вложений) 0

Скандербег 1074 / 987 / 340 Регистрация: 07.08.2012 Сообщений: 2,790
	12.10.2014, 22:39	7
	Сообщение было отмечено aarumyan15267 как решение Решение Судя по объявлению внешних ключей у вас несколько превратное представление о действии связей по внешним ключам между таблицами. Связи между таблицами могут быть физическими по FK для определенных целей (пример выше был приведен) и логическими, по уникальным идентификаторам совсем для других целей (для объединения данных из нескольких таблиц при выборке, например). Видимо, преподаватели еще не донесли до вас такую дифференциацию связей таблиц в базах данных. Именно эти логические связи и спасут вашу работу. А FK здесь вообще ни при чем. В этом вопросе пока виден полный раздрай и не понимание. Поэтому и было рекомендовано убрать FK. Чтобы не мешали записывать данные. 1

@aarumyan15267 0 / 0 / 0 Регистрация: 23.03.2013 Сообщений: 96
	13.10.2014, 00:29 [ТС]	8
	Сообщение от Скандербег и логическими, по уникальным идентификаторам совсем для других целей Извините, но как сделать эти самые логические связи? 0

Скандербег 1074 / 987 / 340 Регистрация: 07.08.2012 Сообщений: 2,790
	13.10.2014, 07:30	9
	Логические связи на примере таблиц Студенты и Группы. В таблице Группы должно быть поле уникального идентификатора строк (назовем его ID - тип Integer). Т.е. каждая запись в этой таблице как бы "маркируется" своим числом. В таблице Студенты есть поле ID_GROUP тоже типа Integer. При записи в таблицу данных о студенте в поле ID_GROUP записывается значение ID из таблицы Группы. Так получаем связь между студентом и нужной группой. FK здесь лишний. В этом и вся логическая связь. При выборке данных по студенту в запросе пишется объединение данных (JOIN) чтобы вместо идентификатора из поля ID_GROUP в программе можно было показать название группы. Про объединения надо читать, здесь не расскажешь. Нужно взять за правило в каждой таблице при ее создании создавать и автоинкрементное поле-идентификатор. Что касается таблиц "Общие сведения" и "Вложения", которые должны быть связаны по полю ID_STUD. Если записи в таблице Вложения должны быть гарантировано удалены при удалении соответствующей записи из таблицы "Общие сведения" (и только в этом случае), то FK создается в таблице Вложения на поле ID_STUD на каскадное УДАЛЕНИЕ ее записей (но не на UPDATE) и ссылающийся на первичный ключ в таблице "Общие сведения" (уник. идентификатор, назовем его тоже ID), . Но и для такого FK есть альтернатива в виде удаления логически связанных (по полям ID_STUD и ID) записей из т. "Вложения" перед удалением соответствующей записи из т. "Общие сведения", которое делается в клиентской программе. Не по теме: Для более удобного манипулирования базой данных вместо IBConsole лучше использовать IBExpert. 0

Operation violates check constraint INTEG_6

Решение