Есть 3 таблицы
tprcs - процессы и их описание
MAIN1 - структура изделия, дерево
spztmp - описывает какой процесс назначен для выполнения на эту деталь на этом изделии
уникальный номер детали - codever
Есть ли возможность какими-нибудь ключами, индексами или еще как обеспечить чтобы при занесении в spztmp записи о назначении процесса значения codever в MAIN1 и tprcs были одинаковыми?
Пока все решается проверкой через код, но может быть можно и по другому?
PS - очень прошу, не надо вопросов зачем мне это надо и почему все организовано так а не иначе

Спасибо.... буду пробовать, но пока совсем не понимаю как....

После каждого этапа разработки я документирую все наименования полей, таблиц, их назначения и тд(модули-функции переменные в функциях). Мне обозначения понятны, в документации описаны, не вижу ни малейшей необходимости что-то менять.

Это неочевидно. Более того - невозможно. И не относится к теме данного топика уж точно. Буду очень благодарен, если кто-нибудь поможет вместо обсуждения структуры составить инструкцию ALTER TABLE ADD CONSTRAINT...

to ПЕНСИОНЕРКА - Хорошо
Таблица MAIN1
Code
OWN код узла и его вышестоящий код - для создания дерева изделия
sernn - уникальный код главного изделия(главной сборки)
codever - уникальный код детали
qt - количество деталей в узле
остальные поля ИМХО несущественны для решаемой задачи

Таблица tprcs
CODE - уникальный код процесса
CODEVER - уникальный номер детали, для которой создан процесс
Остальное - несущественно

Таблица spztmp
CODE - уникальный код записи, в дальнейшем нигде не используется, подумываю удалить
CODM1 - CODE из таблицы MAIN1
cdtp - код назначенного к выполнению для этой детали именно в этой позиции общего дерева изделия процесса
остальное несущественно

Процессов (CODE из tprcs) может быть несколько для одной и той же детали(codever)
На деталь из сборки(code из MAIN1) процесс может быть не назначен, назначен один или назначено несколько процессов

Цель вопроса - предотвратить назначение процессов, разработанных для другой детали.
Как я уже писал - программно через запросы и код я это отслеживаю, но хотелось бы использовать возможности SQL и заодно научиться новому....

На той схеме, что вначале видно, что связь именно по ключевым полям


На той схеме, что сверху я не показал много таблиц, и в честности таблицу VERS с ключевым уникальным полем CODE (codever во всех остальных таблицах), по которому и осуществляется связь с ними
Надеюсь, что из поста выше станет понятно, почему codever присутствует и в табл MAIN1 и и в TPRCS.

Картинка эту я нарисовал для этой темы и пропустил при рисовании , в реальности там правильная связь, такая же как и правая

Мы что сейчас обсуждаем? Спасибо за информацию, но я был бы вам значительно более благодарен, если бы вы помогли реально, а не переводили тему непонятно куда и непонятно зачем.

Darkman, Я задал простой в общем вопрос, точно описал какие поля, где что и как. Не надо тут копаться нигде, не надо обсуждать названия полей, не надо обсуждать структуру базы - вопрос касается только 3-х таблиц.
ЗЫ если не знаете, как помочь реально, то и правда, лучше здесь не писать, не оффтопить.

Mea culpa... confiteor...



Думал про подобное - это действительно самый простой выход. НО очень хотелось(хочется:)) ADD(CHECK) CONSTRAINT понять и научится применять...

Убедили, не буду удалять...

Попробовал так


Выдает ошибку - Ошибка синтаксиса в предложении ограничения CHECK №№ -217217900
Кто поможет разобраться?
Зы - простые CONSTRAINTы научился создавать и удалять

Я естественно знаком с этими понятиями в меньшей степени, чем Вы. И я естественно внимательно прочитал то что вы написали - Второе, требующее анализа и изменения структуры - заново провести анализ. Если появилось требование безуслов6ного соответствия - значит, codever является атрибутом либо сущности из tprcs, либо сущности из MAIN1, и должно присутствовать только там, а для сущности другой таблицы оно должно получаться по связи.

И считаю, что дал объяснения почему все так вот здесь
Таблица MAIN1
Code
OWN код узла и его вышестоящий код - для создания дерева изделия
sernn - уникальный код главного изделия(главной сборки)
codever - уникальный код детали
qt - количество деталей в узле
остальные поля ИМХО несущественны для решаемой задачи

Таблица tprcs
CODE - уникальный код процесса
CODEVER - уникальный номер детали, для которой создан процесс
Остальное - несущественно

Таблица spztmp
CODE - уникальный код записи, в дальнейшем нигде не используется, подумываю удалить
CODM1 - CODE из таблицы MAIN1
cdtp - код назначенного к выполнению для этой детали именно в этой позиции общего дерева изделия процесса
остальное несущественно

Процессов (CODE из tprcs) может быть несколько для одной и той же детали(codever)
На деталь из сборки(code из MAIN1) процесс может быть не назначен, назначен один или назначено несколько процессов

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

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

Далее - ваш текст
Первое, очевидное, решение - создание уникального индекса (code, codever) и связывание таблиц именно по этому выражению, а не просто по (code).
Что имелось ввиду? Создать уникальный составной индекс для табл TPRCS из code+codever? Что это даст? code и так уникальный и что не заноси в codever индекс не даст никаких ограничений
В табл MAIN1 уже есть составной уникальный индекс из codever+own+sernn
Связь между таблицами осуществляется по уникальному(счетчик) и ключевому полю
Если я все же ошибаюсь, то прошу меня поправить