2 Alks
Ага.
Убрать join и "косить" под них.
Тут без hard-programming точно не обойтись.
Хотя, если уж зашли в такие вещи, то дальше уж нам точно
без программинга никак.
Попробую, че получится - выложу. Как-нибудь.
Цитата:
подчинённая запись не может быть сохранёна в реляционной СУБД раньше мастер-записи
Дык, это я согласен абсолютно.
Вопрос же в том, чтобы не
сохранить подчиненный датасоурс раньше
главного, а
проверить подчиненный (и ... главный ... все что угодно), а
потом
сохранить.
И то, что постановка неправильная, я тоже согласен.
Сам не рад, слю-у-у-шай..
У-у-ффффф.
Ща вааще серьезный вопрос задам..
Ж
REM: Открыли по банке пива и приготовились открыть по второй.
2 All !!!
действительно ли противоречит реляционности БД, например, такая вещь:
А)
проверить Контакты
проверить Персоны
сохранить Персоны
сохранить Контакты
и чем она "хуже", чем:
Б)
проверить Персоны
сохранить Персоны
проверить Контакты
сохранить Контакты
?
Т.е., я имею ввиду не сохранение подчиненной
до того,
как был сохранен главный датасоурс,
а
проверку датасоурсов до сохранения.
Чем последовательность, которая сейчас есть в Аксапте,
лучше последовательности, при которой бы
все связанные датасоурсы сначала заполнялись (без
write() при
переходе от одного датасоурс к другому), потом проверялись,
а потом бы в одной транзакции сохранялись?
P.S.:
Не особо люблю грить за всех
, но
Думаю, все (ну или многие) были бы благодарны, если бы вдруг в этой ветке появился
пример, который бы показывал различия между
А) и
Б)
Автору дельного примера, думаю, был бы большой respect.
Ну и .. это.. тему можно было бы закрыть заодно на мажорной ноте..
(Либо я че-то недопонял хде-то
и давайте все сначала )
