Проблема заключается в следующем:
Я незнаю как мне поступать:
Есть 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 писать чтото неясно...

funikovyuri traktor123

Для подобных транзакций есть даже название - long running application transaction. Самое лучшее решение - это оптимистическая блокировка с версионностью.
Т.е. во-первых оптимистическая блокировка - это когда данные в БД будут блокироваться только на период их непосредственной модификации.
Во-вторых версионность тем либо иным способом - проще всего с помощью timestamp колонки. Она нужна так как в отличие от пессимистической блокировки (ваш вариант №2) блокировка на прочитанные ресурсы в начале транзакции ставиться не будет и перед модификацией данных стоит сначала проверить не изменил ли их кто-нибудь до вас.

Если же это решение по тем или иным соображениям не подходит - то тогда вариант 2 - но только в крайнем случае.

а можно же сделать типа вот так:
допустим у меня редактируется в одной транзакции строка мастер и много строк детали:

1. нажимаю на insert/edit(в master форме) - запускаю транзакцию но неделаю никаких блокировок.
(Есть возможность редактировать 1 строку мастера, и много строк детали прикреплённых к этой строке мастера)
2. допустим нужно поменять или добавить какую то строку в деталь.
если нужно поменять(update), я перед этим просто select её for update... и дальше если ошибка что то говорю юзвергу, а если нет ошибки - сразу изменяю...
3. после изменений строки в детали если чё - rollback to savepoint...
4. после всех изменений делаю commit/rollback в мастер таблице.

????

funikovyuri traktor123

а можно же сделать типа вот так:

вы описываете вариант пессимистической блокировки. Я правда не понял как это открывать транзакцию и ничего не блокировать? Ну и for update - это просто обязательно, если вы в транзакции читаете данные, которые впоследствии планируете модифицировать


Еще немного слов про оптимистическую блокировку. На данный момент большинство средств доступа к БД автоматически поддерживают timestamp для контроля версий и batch updates для пакетного обновления. Поэтому общий сценарий достаточно прост

Читаете данные (с помощью простых select'ов без for update)
Работаете с ними

Выполняете пакетное обновление в одной транзакции. При этом для каждого модифицируемого ресурса проверяете версии на клиенте и на сервера (обычно для этого ничего делать не надо так как большую часть работы на себя берет слой доступа к данным - будь то ADO или JDBC) Если все нормально - фиксируете транзакцию. Если же что-то уже было изменено - то, обычно, откатываете ее

а что такое timestamp ???

funikovyuritimestamp - тип данных. Посмотрите документацию к вашей СУБД

ага т.е. это самому нужно организовывать поле с времененм и проверять его ?

funikovyuriобычно достаточно организовать поле - все остально будет делать БД и интерфейс доступа

PS> пора бы раскрыть что за БД и на чем написан клиент :)
oracle, delphi неподскажите примерчик ???