EstetsТранзакциями тут никак не обойтись, нельзя открыть транзакцию на час.
Сомнительное утверждение.

EstetsМы пошли по другому пути запись сохраняется в основную таблицу но с пометкой что запись "неактуальна",
Можно. Но я бы не стал так делать. Со свойственным мне экстремизмом я плохо отношусь к мусору в БД, благо видел и ощущал, сколько удовольствия он доставляет в поддержке и сопровождении.

В такой ситуации я бы скорее воспользовался кэшированными изменениями.

EstetsКонечно ее можно удалить потом скриптом, но из опыта количество таких записей не превышает 5% и на производительность они не влияют.
На производительность - не влияют. Влияют на программистов, которые в ста из десяти тысяч мест забудут написать "and flag_active = 1".

EstetsУгу только вот сам встречался с "программистами" которые пишут на клиенте ..... а потом удивляются
Тем не менее я не вижу никаких оснований лупить глобальными утверждениями там, где речь может идти о частных проблемах конкретного решения. Это будет ровно так же оправданно, как если я скажу "надо делать транзакцию на час, никаких проблем не будет и никакого другого решения никогда понадобиться не может, дурь это все".

EstetsИ такое бывает. Правда у нас был не флаг, а поле "статус",
Я бы сказал не "бывает", а "будет". При такой структуре избежать этой проблемы практически невозможно; можно только минимизировать вероятность ее возникновения (в частности - не вводить лишних состояний).

EstetsК сожалению я не знаю другого алгоритма внесения MASTER-DETAIL с возможностью откатить вставку и того и другого.
Хм. Кэширование изменений на клиенте. Для Oracle я не люблю это решение, но для блокировочников оно представляется мне оптимальным вариантом. В моем единственном проекте на MSSQL так и работает.

EstetsМожно конечно попытаться использовать временные таблицы, или структуры в памяти, но тогда возникают проблемы с изменением записей.
Не очень понимаю, о чем Вы. Для блокировочника единственно потребуется внетранзакционный механизм блокирования документов.

ModelRА вью на что?
Не на это :)

Согласен, view способны уменьшить количество таких ошибок, но во-первых не до нуля, а во-вторых, цена такого решения будет ненулевой. По сути, программист должен помнить и выполнять правило "нужно использовать вьюхи" вместо правила "нужно проверять статус". При этом элементарно удваивается количество объектов, о которых должен помнить|думать программист; ряд запросов таки должны идти к таблицам итп. Кроме того, в некоторых БД есть претензии к быстродействию view.

Kezya softwarerВ такой ситуации я бы скорее воспользовался кэшированными изменениями.
Подскажите, пожалуйста, что это такое?
Хм. Собственно, данные вместе со всеми модификациями хранятся на клиенте (много строк) до той поры, пока не нажимается большая красная кнопка и полный набор изменений одним пакетом отсылается на сервер. Технологическая реализация может быть самой разной, но если подумать, ее можно сделать вполне удобной. Для ввода документов - обычно подходит без проблем, хотя разумеется есть свои ограничения; основное - серверная логика также вынуждена выполняться чохом, в момент сохранения. Когда это может быть неудобным.... например, если Вы хотите сразу в момент создания строки в накладной резервировать товар для этой строки.

KezyaУ меня похожая ситуация: добавленная строка влечет за собой дальнейшие действия в базе.
Скажу так: по моему опыту перенос отработки логики с момента ввода данных на момент их сохранения не вызывает принципиальных проблем. Но не собираюсь настаивать на нравящемся мне решении; каждый выбирает тот геморрой, который ему более по душе.

EstetsЭто все я к тому что открывать транзакцию, вставлять запись и давать пользователю ее редактировать, это самый неудачный вариант решения проблемы.
Это самый удачный вариант решения проблемы.

Я почему-то абсолютно уверен, что если загляну в Ваш профиль, обнаружится, что Вы MSSQL-щик (не DB2-шник, не Access-ник, а именно MSSQL). Это к сожалению общая и весьма раздражающая черта специалистов по этому серверу - считать, что других в природе не существует и формулировать местечковую мудрость так, словно это закон природы.

EstetsС многими вашими утверждениями согласен, но данное утверждение применительно к блокировочникам буду оспаривать, что называется до последнего
Как раз в этом и состоит моя цель. Надеюсь, на этом примере Вы увидите, что Ваше утверждение применительно к версионникам выглядит столь же... спорно. А следовательно в топике, где ни слова не сказано об используемой БД, нет места ни тому, ни другому.

EstetsДанное решение возможно в частном случае
Данное решение отлично работает в общих случаях. Разумеется, как и у любой технологии, у него есть свои ограничения, но они непринципиальны. Собственно, мне известны два проекта на десяток человеко-лет каждый, полностью реализованные в такой технологии - полагаю, Вам придется согласиться, что это свидетельство достаточно общего случая.

EstetsДостаточно просто дать оператору заполнить данные в буфферах, массивах, структурах
:((

EstetsНо во первых данное решение требует программирования каждой формы использующей отношение MASTER-DETAIL.
Какая жуть :(( Простите, но говорить так - показывать незнание такого повсеместно презираемого сейчас паттерна проектирования, как "выделение стандартных подпрограмм". Ну или более современных - например, "проектирование базовых классов".

Реализация мастер-детали укладывается в считанные строки базового класса "фрейм ввода данных" и позволяет беспроблемно строить сколь угодно сложные иерархии. Например, у меня в такой схеме работал конфигурируемый модуль ввода информации по физюрлицам, банкам итп; полагаю, Вы согласитесь, что информации там достаточно много, и вложенность типа "телефоны сотрудников организации" вполне в порядке вещей.

EstetsВ результате структура кэша усложняется неимоверно, усдажняется соответственно и написание кода по вставке всего в БД.
Хм. Такое впечатление, что Вы говорите о технологиях программирования позапрошлого века. Хорошо написанная сложная программа состоит из множества простых кирпичиков и достаточно проста в реализации.

Согласен, на блокировочнике придется уделить внимание некоторым вещам, которые в версионнике легко решаются. Например, частичный откат - если вы из формы1 вызвали форму2, из формы2 вызвали форму3, в форме3 нажали Ok, а в форме2 - Cancel. Но я не вижу здесь ничего, что я не взялся бы эффективно (то есть хорошо и в разумные сроки) реализовать.

EstetsА как говорится это только начало, при изменении записи нам либо придется поднимать весь кэш на клиента либо опять писать отдельный код по обработке отдельно ИЗМЕНЕНИЯ - УДАЛЕНИЯ записей.
Зачем? Мне вспоминается эпизод из Гаррисона, где главный герой увидел толпу рабов, крутивших статор вокруг ротора - "если есть два пути что-то сделать, эти выберут худший".

EstetsИ как решить все это безобразие я например не знаю. Мы пошли по пути вставки "неактуальной" записи, если есть другие решения с удовольствием готов их выслушать.
Собственно сказал. У меня был проект, где заказчик захотел некий не очень с моей точки зрения обоснованный слой доступа к данным - по сути, грузить данные из БД на клиента, там ими оперировать и так вот кэшированно скидывать обратно. Я сейчас посмотрел - модуль, содержащий базовые классы для работы этого слоя, занимает порядка двух тысяч строк. Если добавить в него всю функциональность, которую я себе в принципе представляю для такой задачи - получится... думаю, тысяч пять.