Цитата:
Сообщение от
Gustav
Меня смущает другое: если можно ввести кривой релейшн, то как на него система реагирует в дальнейшем? Просто игнорирует?
По сути - релейшны нужны для организации лукапов и переходов к основной таблице - по умолчанию, без каких либо перекрытий в форме. Ну и заодно - служат проверкой при сохранении записи (чтобы выбирали только значения из лукапа).
Т.е. по приоритетам, в порядке убывания строится так:
1. (самый важный) - перекрытый метод lookup/jumpref
2. (если методы не перекрыты) - согласно информации о релейшнах на таблицах
3. (если информация на таблицах отсутствует) - согласно информации о релейшнах на расширенном типе данных.
Если будет кривой релейшн то система может отреагировать двояко:
1) Если сумеет разобраться - то построит лукап и переход к основной таблице и будет делать проверку введенного значения. (Вопрос - будет ли полученный результат совпадать с желаемым)
2) Если не сумеет разобраться (или же как здесь - поле возможно было удалено) - то просто проигнорирует релейшн (будет искать правильный релейшн на расширенном типе данных)
Цитата:
Сообщение от
Gustav
P.S. Relations вообще несут какую-нибудь нагрузку в плане контроля целостности и т.п.? Или это не более чем информация о, скажем так, "рекомендуемо-предполагаемой" связи таблиц, которую в принципе можно нарушить вводом в связанные таблицы данных, которые не будут соответствовать этой связи?
Не-а. Не несут. Информация может использоваться в перекрестных ссылках, при построении запроса (querybuilddatasource.relations(true)); при построении пользовательского запроса (по Ctrl+F3) - при добавлении таблицы или еще в подобных ситуациях.
Цитата:
Сообщение от
Gustav
P.S.2. И еще вопрос. Конкретный Relation по определению относится к двум таблицам. В репозитарии же конкретный Relation указывается только на одной таблице из двух. Вопрос - на какой? На той, которая на стороне "многие" в отношениии "1:многие"? Или действует какой-то другой принцип?
Да, там где многие. См табл custTrans и rcontractTable