Ограничения полей в IB

← →
Анатолий (2002-11-29 15:09) [0]

Как в IB описать поля (домены?) startDate & endDate при ограничениях
startDate >= "сегодня" DEFAULT "сегодня"
endDate >= startDate

← →
Victor_Cr (2002-11-29 15:26) [1]

А для каких целей, можно узнать? Я к тому что, а вдруг это можно сделать по другому.

← →
Анатолий (2002-11-29 16:05) [2]

Таблица должна содержать колонки
Дата начала договора
Дата закрытия договора.
Здравый смысл подсказывает, что договор не может быть закрыт раньше, чем он составлен. При этом доовор не может быть составлен вчерашним числом. Кроме того, удобно было бы автоматически проставлять текущую дату для поля Дата начала договора.

← →
roottim (2002-11-29 16:12) [3]

если вы даже зададите такие ограничения, то как вы хотите хранить вчерашние докуметы?, ведь они уже непопадают в вашу область.
Выход. Реализовывать ограничение на уровне клиента.

← →
Prooksius (2002-11-29 16:16) [4]

Конечно можно и нужно по-другому.
В таблице делаешь проверку, не является ли поле начала договора больше, чем окончания (check BeginDate < EndDate)
А в триггере проверяешь, чтобы BeginDate был = сегодня
В клиенте при новом договоре по умолчанию ставишь в соотв. поле сегодня.

← →
Prooksius (2002-11-29 16:17) [5]

2 roottim (29.11.02 16:12)
Если это возможно, лучше перенести такие проверки на сервер.
В данном случае это возможно.

← →
Val (2002-11-29 16:20) [6]

По теме:
"сегодня" - это, кажется, Now, вернее это "сейчас", но, если нет сис. переменной типа Today, то можно просто обрезать время у Now.
Но, если, проблема стоит, как описано в Анатолий (29.11.02 16:05), то это несколько некорректное решение. Удобнее и правильнее решать эти вопросы с помощью средств сервера.
>roottim (29.11.02 16:12) - именно сервера, для чего существуют триггера и хп?

← →
Val (2002-11-29 16:21) [7]

сорри за некоторый повтор Prooksius ©, отвлекся и опоздал запостить :(

← →
Victor_Cr (2002-11-29 16:36) [8]

Пишешь триггер, который проверяет перед вставкой или изменением,
для вставки даты создания договора:
new.BeginDate := "now";

для проверки даты закрытия:
if new.BeginDate < new.EndDate then
Создаешь исключительную ситуацию или new... := old...;

← →
Анатолий (2002-11-29 17:17) [9]

Я имел ввиду такое вот решение проверки D2>D1:
CREATE TABLE TEST
(
D1 DATE,
D2 DATE,
CHECK(D2>D1)
);
Это я пишу в окне InteractiveSQL, но во вкладке IBCOnsole-TableProperties-Metadata по непонятным мне причинам прописано:
CREATE TABLE TEST
(
D1 TIMESTAMP,
D2 TIMESTAMP
);
Эта конструкция работает.
А для DEFAULT "сегодня" предполагал написаить что-то типа
CREATE TABLE TEST
(
D1 DATE DEFAULT "не знаю какая сис. переменная",
D2 DATE,
CHECK(D2>D1)
);

← →
Victor_Cr (2002-11-29 22:03) [10]

Понимаешь на уровне домена типа ты можешь указать только ограничения для данного поля. Все остальные проверки делаются из триггеров, это хороший стиль программирования баз данных. Покрайней мере надежность БД, защита от случайных изменений (ошибок, диверсий) повышается. Будет лучше делать проверку именно в триггере. Если чего-то непонятно в самом процессе создания триггера, то поищи в интернете документацию. Это не сложно (я имею в виду написание триггеров), и достаточно познавательно. :-)

← →
Tlotr (2002-11-30 02:05) [11]

Рекомендую отказаться от консоли в пользу IBExpert.
www.ibexpert.com/download
Для xUSSR бесплатно, за что разработчикам ОГРОМНОЕ ПАСИБО.
Наиболее удобная программа управления IB.

← →
kaif (2002-11-30 03:23) [12]

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

Ограничения полей в IB Найти похожие ветки