Проблема заключается в следующем:
Я незнаю как мне поступать:
Есть Master форма ввода.
к ней прикреплена detail форма - также форма ввода.
когда Master форма ввода находится в режиме редактирования, в detail форму имеется возможность добавления строк...(там своя панель навигации и всё такое т.е. полноценная форма ввода только detail)
но если я передумаю сохранять строку в Master форме, все сохранения детали также должны отменится.

я вижу 2 выхода из положения:

1. Делать все изменения в детали до отмены или применения в mastere - локально, т.е. чтобы сервер про них ничего незнал...
а потом посылать всё пакетом на сервер или отменять когда жму на применить/отмена в Master форме ввода.

Но здесь проблема с рисунками - если юзверг захочет в детали добавить 10 строк с рисунками непонятно что тогда делать ??? можно ли в датасете
(я юзаю одак но думаю здесь это не принципиально) локально хранить рисунки в разных строках ??? - а создавать списки хранить список рисунков в памяти это довольно гиморно...

2. Можно растянуть транзакцию между кнопочками Insert и Post/Cancel....
тогда никаких проблем с отменами изменений небудет всё будет сохранятся/отменятся правильно НО:
есть следующие недостатки
1. Период редактирования одной Master записи, теоретически может растянутся на целый день(ктото начнёт редактировать, забудет перейти в режим просмотра и пойдёт домой...) - в это время я думаю что чтото будет заблокировано...... - незнаю насколько это серьёзно(у нас неочень много людей с базой будет работать и в основном с разными непересекающимися частями таблиц но всё может быть...)
2. В пределах этой транзакции нельзя будет делать другие транзакции до того как я неперейду в режим проспотра( ну или можно но нужно будет продумывать как всё делать чтобы незапутыватся...)


Может есть какойто другой вариант ?
Посоветуйте как мне сделать такую связку Master/Detail ???

Спасибо!!!

ЗоринАндрейЕсть вариант с дополнительными таблицами.
Т.е. Начали редактировать master - занесли запись во "временную" таблицу.
работаем с detail - заносим в соответствующую "временную" таблицу.
По Ok в мастере - перенос INSERT INTO постоянная SELECT FROM временная плюс убиение записей во временной.
По Cancel - только убиение во временной.
Временная периодически чистится от "повисших" устаревших записей которые по какой-то причине не были удалены пользователем.
Плюс в том что все транзакции короткие, и пользователи не будут кричать "что это такое. я только пообедать отошел а у меня все пропало".
Вы ж ему не будете объяснять что транзакцию убили из-за блокировок или там "сервер про них ничего незнал". ;-)


З.Ы. Что такое ОР в subj-е?

блин ну вы как маленький :-) OP - опыт работы ;-)

Т.е. нужно всеё делать на клиенте, а потом 1 раз отправлять ?

Dmitry Biryukov Один Dmitry Biryukovу меня всё построено на отсоединённых рекордсетах
...
Минус, конечно - надо разруливать одновременное редактирование одной записи несколькими пользователями. Небольшой такой минус.
Что характерно, никак не решает проблему traktor123
О размерах минуса можно спорить бесконечно долго :-)
А задачу этот подход всё-таки решает
traktor123если я передумаю сохранять строку в Master форме, все сохранения детали также должны отменится
В предложенном мною подходе все изменения делаются в локальном рекордсете и при нажатии "отмена" на сервер не передаются.

вопрос: а нет ли заложенной ошибки в таком локальном потходе: если я всё подготавливаю на клиенте а потом отправляю, а в этот момент другой юзер с этими данными также делает изменения... потом мы отправляем вместе на сохранение.... какието данные пропадают.... ????????

Andrey traktor123вопрос: а нет ли заложенной ошибки в таком локальном потходе: если я всё подготавливаю на клиенте а потом отправляю, а в этот момент другой юзер с этими данными также делает изменения... потом мы отправляем вместе на сохранение.... какието данные пропадают.... ????????
вопрос справедливый, но все зависит от того как будет спроектирован клиент. Если при попытке сохранить получите сообщение об ошибке Вы можете проинформировать пользователя и даже, к примеру, показать какие именно поля были изменены.

а если я сразу запускаю транзакцию, без всяких CachedUpdates, а потом rollback или commit - то таких проблем не возникнет...???, по логике перед началом редактирования будет выдано сообщение запись заблокированна, или как ???

и ещё вопрос: сколько обычно делают сессий подключения к ораклу(ну или другой бд...) ????

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

и какже сделать чтобы при длинных транзакциях редактирования ничего другим не мешало ???

gardenmanпросто используйте грязное чтение, если конечно сможете)))

а зачем грязное чтение ???, лучше уж старые данные читать...

traktor123 gardenmanпросто используйте грязное чтение, если конечно сможете)))

а зачем грязное чтение ???, лучше уж старые данные читать...

запись же не блокирует чтение... ?

и ещё вопрос: вы не знаете в оракле при редактировании записи, блокируется только эта запись или нет ?

tru55 traktor123
запись же не блокирует чтение... ?

и ещё вопрос: вы не знаете в оракле при редактировании записи, блокируется только эта запись или нет ?

1. Не блокирует

2. Если не используется SELECT...FOR UPDATE, то блокируется только одна запись

круто... т.е. как я понял:
1. обычный селект вообще ничего не блокирует ???
2. insert, update, delete - блокируют для записи те строки, которые попадают в их условие отбора ???
3. Select for Update - также как и п2. - блокирует для записи кот попали в усчловие отбора для записи... ???
и ещё вот:
4. Если я перед транзакцией не вызываю set transaction или чтото ещё, то просто записи блокируются последовательно, и с теми атрибутами(для чт иди для зап) которые необходимы для данной DML комманды ????

tru554. Перед транзакцией не надо вызывать "set transaction или чтото ещё". Она начинается с первого DML-оператора, выданного после COMMIT/ROLLBACK.
Строки действительно блокируются в порядке выполнения операторов.
А насчет атрибутов я не понял

ну атребуты я имел ввиду блокировать для чтения или блокировать для записи...

я знаю что set transaction ненужно вызывать для старта транзакции ;-)

Я хотел спросить если блокировки идут последовательно, и тип блокировки определяется самой DML коммандой, то зачем тогда нужна Set transaction ???

tru55 traktor123
я знаю что set transaction ненужно вызывать для старта транзакции ;-)

Я хотел спросить если блокировки идут последовательно, и тип блокировки определяется самой DML коммандой, то зачем тогда нужна Set transaction ???

А как соотносятся эти две фразы???

PS Блокировки нужны ТОЛЬКО для изменения

вы же oracle юзаете ??? set transaction <параметры> - нужна для предварительного сообщения ораклу какого типа эта транзакция (нормальная для грязного чтения...) только я неврубаюсь чтото зачем это нужно, точнее зачем я понимаю - чтобы блокировки сделать более оптимально, но когда какую set transaction писать чтото неясно...