Непонятки с внешним ключом

[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-значения.
Как побороть это сообщение сервера?

[Merlin]

есть таблица
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-значения.
Как побороть это сообщение сервера?

Посмотреть на описание домена TID_NULL не в комментариях, а наяву, и убедиться, что там написано Not Null?

[kdv]

есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,

Однако проблема именно в том, что в качестве FK (и где то значит PK) используется NUMERIC(18,3). Если это третий диалект, то это int64, а если 1-ый, то double precision.
В обоих случаях практически никогда для идентификаторов не требуется такой разрядности. Поэтому использовать надо ОБЫЧНЫЙ INTEGER.

А NUMERIC(18,3) - для числовых значений, зарплата там, кол-во ящиков и т.п.

[Merlin]

есть таблица
CREATE TABLE CONTRACTS_TAB (
...
EMPLOYER TID_NULL /* TID_NULL = NUMERIC(18,3) */,

Однако проблема именно в том, что в качестве FK (и где то значит PK) используется NUMERIC(18,3). Если это третий диалект, то это int64, а если 1-ый, то double precision.
В обоих случаях практически никогда для идентификаторов не требуется такой разрядности. Поэтому использовать надо ОБЫЧНЫЙ INTEGER.

А NUMERIC(18,3) - для числовых значений, зарплата там, кол-во ящиков и т.п.

Казалось бы, при чём тут Лужков, то есть тьфу, проверка на Null? И какой найк 18,3 в первом диалекте? 15 максимум

[Gelios]

диалект 3.
для данной задачи часть PK и FK имеют тип NUMERIC(18,3). использовать ОБЫЧНЫЙ INTEGER для данной задачи практичеки невыполнимо (нужно будет полностью переделать базу на оракле и всех клиентов другой задачи, с которой связана проектируемая задача, а этого никто не будет делать). следовательно нужно как то выкручиваться с таким типом. (можно конечно отключить FK, но не хотелось бы...)

[Gelios]

Посмотреть на описание домена TID_NULL не в комментариях, а наяву, и убедиться, что там написано Not Null?

CREATE DOMAIN TID_NULL AS
NUMERIC(18,3)

[Андрей Могильный]

Не знаю как насчет доменов, но у нас имеется достаточное количество NULL-ВК при ПК и ВК - INTEGER.
Так что либо тут бага (предположительно из-за использования домена), либо ты чего не видишь. Еще раз внимательно и с фонариком... Или попробуй сделать тесты на выявление бага.

[Gelios]

интересная ситуация. сменил у полей FK/PK тип на integer, потом снова вернул тип numeric(18,3) теперь работает...
правда другая проблемка вылезла:
по этой таблице создано представление (есть триггеры на вставку/замену/удаление). если теперь вставляь запись не через таблицу а через представление, и поле employer в команде на вставку не указан (или там значение null) то выходит вышеописанная ошибка. если в триггере прописать какое либо значение, то вставеа проходит нормально. такие же ошибки идут и с другими полями, которые описаны с атрибутом not null, но значение которым присваивается в триггере (либо на представление, либо на таблицу)

[Gelios]

тему можно закрыть.
проблему решил обходным маневром.

[Odysseos]

Надо было проверить не только 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 особенно широко пользовать представления - геморроя зачастую с ними больше, чем пользы).