Проверка подчиненных записей

[lego_99]

2 Alks

Ага. Убрать join и "косить" под них.
Тут без hard-programming точно не обойтись.
Хотя, если уж зашли в такие вещи, то дальше уж нам точно
без программинга никак.
Попробую, че получится - выложу. Как-нибудь.

Цитата:

подчинённая запись не может быть сохранёна в реляционной СУБД раньше мастер-записи

Дык, это я согласен абсолютно.

Вопрос же в том, чтобы не сохранить подчиненный датасоурс раньше
главного, а проверить подчиненный (и ... главный ... все что угодно), а
потом сохранить.

И то, что постановка неправильная, я тоже согласен.
Сам не рад, слю-у-у-шай..

У-у-ффффф.
Ща вааще серьезный вопрос задам.. Ж
REM: Открыли по банке пива и приготовились открыть по второй.

2 All !!!
действительно ли противоречит реляционности БД, например, такая вещь:

А)
проверить Контакты
проверить Персоны
сохранить Персоны
сохранить Контакты

и чем она "хуже", чем:

Б)
проверить Персоны
сохранить Персоны
проверить Контакты
сохранить Контакты
?

Т.е., я имею ввиду не сохранение подчиненной до того,
как был сохранен главный датасоурс,
а проверку датасоурсов до сохранения.

Чем последовательность, которая сейчас есть в Аксапте,
лучше последовательности, при которой бы
все связанные датасоурсы сначала заполнялись (без write() при
переходе от одного датасоурс к другому), потом проверялись,
а потом бы в одной транзакции сохранялись?

P.S.:
Не особо люблю грить за всех , но
Думаю, все (ну или многие) были бы благодарны, если бы вдруг в этой ветке появился
пример, который бы показывал различия между А) и Б)
Автору дельного примера, думаю, был бы большой respect.
Ну и .. это.. тему можно было бы закрыть заодно на мажорной ноте..
(Либо я че-то недопонял хде-то и давайте все сначала )