Непонятки с внешним ключом
Непонятки с внешним ключом
есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,
.....
);
ALTER TABLE CONTRACTS_TAB ADD CONSTRAINT FK_CONTRACTS_TAB_EMPLOYER FOREIGN KEY (EMPLOYER) REFERENCES CLIENTS_TAB (ID);
остальные поля несущественны
при попытке вставить запись с полем employer, содержащим null, сервер (Yaffil 885) выдает ошибку
The insert failed because a column definition includes validation constraints.
validation error for column EMPLOYER, value "*** null ***".
хотя, если мне не изменяет память, внешние ключи поддерживают null-значения.
Как побороть это сообщение сервера?
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,
.....
);
ALTER TABLE CONTRACTS_TAB ADD CONSTRAINT FK_CONTRACTS_TAB_EMPLOYER FOREIGN KEY (EMPLOYER) REFERENCES CLIENTS_TAB (ID);
остальные поля несущественны
при попытке вставить запись с полем employer, содержащим null, сервер (Yaffil 885) выдает ошибку
The insert failed because a column definition includes validation constraints.
validation error for column EMPLOYER, value "*** null ***".
хотя, если мне не изменяет память, внешние ключи поддерживают null-значения.
Как побороть это сообщение сервера?
Re: Непонятки с внешним ключом
Посмотреть на описание домена TID_NULL не в комментариях, а наяву, и убедиться, что там написано Not Null?Gelios писал(а):есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,
.....
);
ALTER TABLE CONTRACTS_TAB ADD CONSTRAINT FK_CONTRACTS_TAB_EMPLOYER FOREIGN KEY (EMPLOYER) REFERENCES CLIENTS_TAB (ID);
остальные поля несущественны
при попытке вставить запись с полем employer, содержащим null, сервер (Yaffil 885) выдает ошибку
The insert failed because a column definition includes validation constraints.
validation error for column EMPLOYER, value "*** null ***".
хотя, если мне не изменяет память, внешние ключи поддерживают null-значения.
Как побороть это сообщение сервера?
Re: Непонятки с внешним ключом
Однако проблема именно в том, что в качестве FK (и где то значит PK) используется NUMERIC(18,3). Если это третий диалект, то это int64, а если 1-ый, то double precision.Gelios писал(а):есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,
В обоих случаях практически никогда для идентификаторов не требуется такой разрядности. Поэтому использовать надо ОБЫЧНЫЙ INTEGER.
А NUMERIC(18,3) - для числовых значений, зарплата там, кол-во ящиков и т.п.
Re: Непонятки с внешним ключом
Казалось бы, при чём тут Лужков, то есть тьфу, проверка на Null? И какой найк 18,3 в первом диалекте? 15 максимумkdv писал(а):Однако проблема именно в том, что в качестве FK (и где то значит PK) используется NUMERIC(18,3). Если это третий диалект, то это int64, а если 1-ый, то double precision.Gelios писал(а):есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,
В обоих случаях практически никогда для идентификаторов не требуется такой разрядности. Поэтому использовать надо ОБЫЧНЫЙ INTEGER.
А NUMERIC(18,3) - для числовых значений, зарплата там, кол-во ящиков и т.п.
диалект 3.
для данной задачи часть PK и FK имеют тип NUMERIC(18,3). использовать ОБЫЧНЫЙ INTEGER для данной задачи практичеки невыполнимо (нужно будет полностью переделать базу на оракле и всех клиентов другой задачи, с которой связана проектируемая задача, а этого никто не будет делать). следовательно нужно как то выкручиваться с таким типом. (можно конечно отключить FK, но не хотелось бы...)
для данной задачи часть PK и FK имеют тип NUMERIC(18,3). использовать ОБЫЧНЫЙ INTEGER для данной задачи практичеки невыполнимо (нужно будет полностью переделать базу на оракле и всех клиентов другой задачи, с которой связана проектируемая задача, а этого никто не будет делать). следовательно нужно как то выкручиваться с таким типом. (можно конечно отключить FK, но не хотелось бы...)
Re: Непонятки с внешним ключом
CREATE DOMAIN TID_NULL ASMerlin писал(а):Посмотреть на описание домена TID_NULL не в комментариях, а наяву, и убедиться, что там написано Not Null?
NUMERIC(18,3)
-
- Сообщения: 12
- Зарегистрирован: 26 окт 2004, 15:47
интересная ситуация. сменил у полей FK/PK тип на integer, потом снова вернул тип numeric(18,3) теперь работает...
правда другая проблемка вылезла:
по этой таблице создано представление (есть триггеры на вставку/замену/удаление). если теперь вставляь запись не через таблицу а через представление, и поле employer в команде на вставку не указан (или там значение null) то выходит вышеописанная ошибка. если в триггере прописать какое либо значение, то вставеа проходит нормально. такие же ошибки идут и с другими полями, которые описаны с атрибутом not null, но значение которым присваивается в триггере (либо на представление, либо на таблицу)
правда другая проблемка вылезла:
по этой таблице создано представление (есть триггеры на вставку/замену/удаление). если теперь вставляь запись не через таблицу а через представление, и поле employer в команде на вставку не указан (или там значение null) то выходит вышеописанная ошибка. если в триггере прописать какое либо значение, то вставеа проходит нормально. такие же ошибки идут и с другими полями, которые описаны с атрибутом not null, но значение которым присваивается в триггере (либо на представление, либо на таблицу)
все проблема, видимо, в другом
Надо было проверить не только not null у домена, но и not null У УЖЕ СОЗДАННОГО ПОЛЯ с этим доменом!
Была такая бяка - то ли Yaffil в том был виноват, то ли давние версии IBExpert'а... Короче - если создать поле с каким-либо доменом, где у домена есть constraint not null, то поле создавалось так:
field field_type not null
Соответственно, если потом у домена not null прибить - у поля он оставался!
Кстати - на текущей версии IBExpert'а (2004.10.18 и уже давно, в общем-то) и Firebird 1.5.x - такого вот нюанса при создании полей с доменами not null не наблюдается.
А с представлениями - при создании представления constraint'ы полей оно запоминает те, которые были на момент создания, и потом, при их изменении для таблиц/доменов - у представления они остаются _старыми_, а потому его надо прибивать/создавать заново (потому и не рекомендуется в IB особенно широко пользовать представления - геморроя зачастую с ними больше, чем пользы).
Была такая бяка - то ли Yaffil в том был виноват, то ли давние версии IBExpert'а... Короче - если создать поле с каким-либо доменом, где у домена есть constraint not null, то поле создавалось так:
field field_type not null
Соответственно, если потом у домена not null прибить - у поля он оставался!
Кстати - на текущей версии IBExpert'а (2004.10.18 и уже давно, в общем-то) и Firebird 1.5.x - такого вот нюанса при создании полей с доменами not null не наблюдается.
А с представлениями - при создании представления constraint'ы полей оно запоминает те, которые были на момент создания, и потом, при их изменении для таблиц/доменов - у представления они остаются _старыми_, а потому его надо прибивать/создавать заново (потому и не рекомендуется в IB особенно широко пользовать представления - геморроя зачастую с ними больше, чем пользы).