При предложенном вами способе обновления вы 100% уверены, что все изменения пройдут в контексте одной транзакции?
Например MSSQL, да и PGSQL любят, если явно не указано, то отдельные апдейты делать в разных транзакциях. Т.е. транзакция автоматом начинается и заканчивается для каждой операции.
А потом с вас пользователи спросят - почему данные не валидны...
Добавлено спустя 5 минут 59 секунд:
Ism писал(а): MasterField MasterSource
Когда я попытался это воспроизвести это в tsqlquery из лазаруса , такое уродство вышло.
Я уже не говорю о том, что если вы таким образом свяжете эти два объекта - у вас такой объём данных по сети будет гонятся, что и сеть положить можно, не говоря о бедном сервере.
Почему не подумать немного над запросом и сразу связать несколько таблиц и выбрать только необходимый минимум.
А если уже хочется мастер-детайл для оператора, то опять-таки - указывая явно запосы вы очень сильно уменьшаете объём данных.
PS
Вот чего мне не хватает в ZEOS-е так это вот этого - http://www.devrace.com/ru/fibplus/artic ... hp?ID=1172
Вторая важная опция - это ключ dcWaitEndMasterScroll. Представьте, что пользователь передвигается по DBGrid1, пытаясь найти нужный отдел. При каждом движении, когда меняется текущая запись в DBGrid1, pFIBDataSet2 автоматически переоткрывает запрос. Очевидно, движение по master-таблице может вызвать серию довольно "тяжелых" запросов, которые значительно увеличат совершенно бесполезный сетевой трафик. На практике было нужно переоткрыть detail-запрос только один раз, когда пользователь все-таки нашел нужный ему отдел в DBGrid1. FIBPlus позволяет избежать ненужных запросов. Если ключ dcWaitEndMasterScroll добавлен в DetailConditions, то detail-запрос переоткрывается только после некоторой паузы (величину паузы можно регулировать, задавая значение свойства WaitEndMasterInterval).
Таким образом, когда пользователь просто передвигается по DBGrid1, изменение текущей записи "включает" таймер detail-запроса. Если за время паузы пользователь успевает перейти на другую запись, то таймер сбрасывается. И так до тех пор, пока пользователь не остановится на нужной записи. Только после этого detail-запрос переоткрывается, а значит, pFIBDataSet2 выполняет только один запрос вместо целой серии.