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

Один1Ну вы сделали версионник своими руками.
Это пожалуй что слишком сильное утверждение :) Хотя как афоризм - согласен.

Один1Наверное вам так привычнее, хотя мне кажется, что это более трудозатратное решение, чем введение статусов.
Такое сравнение без дополнительных оговорок не совсем корректно. Подобная технология и инструментаций ее поддержки - это разовые трудозатраты. Имхо - разумные по размеру, хотя понятно, что это зависит от инструментария разработки и других факторов. Ведение статусов - трудозатраты постоянные. Соответственно, для одного проекта на человеко-недели такой подход сомнителен, как стандартная библиотека даже для одинокого фрилансера - имхо оправдано.

Один1Это хороший способ, но в блокировочниках так нельзя. П.э. для блокировочников это "самый неудачный вариант решения проблемы". Не только для MSSQL.
Безусловно. Но почему-то тот же gardenman не склонен к подобным глобальным формулировкам до того, как оговорена БД, а вот именно от mssql-щиков такое слышно постоянно (согласен, наверяка есть и те, кто не склонны. Но процентное соотношение...).

EstetsТогда стоит наверное сказать на каких типах БД построены данные приложения? Если мы рассматриваем версионники и блокировочники. Или это тоже частный случай применимый только к версионникам?
Эти приложения - для версионников. У меня для блокировочника единственный проект и кардинально менее крупный.

В то же время как раз здесь я не вижу приниципиальной разницы. Раз уж "версионник на клиенте", как выразился Один1 , не так важно с чем он работает.

EstetsЕсли бы все было так просто, не было бы таких флеймов.
Я не знаю PowerBuilder и готов допустить, что на нем все непросто. Насколько я слышал, это продукт с достаточно жестко прописанной идеологией разработки.

EstetsНу со своей стороны могу сказать что семейство программ, которые я проектировал используют в 90 процентах три базовых объекта для обработки списка, редактора и фильтра. Уж как говорится объектнее некуда.
Э-э, очень даже есть куда. Обратите внимание, что названы по сути три визуальных компонента и все. Это "объектно" по той же логике, по которой ООП отождествляют с "киданием компонент на форму" в дельфе - типа раз компоненты, значит уже крутой ООпер.

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

Это более сильное решение, чем "cached updates вообще" и тем не менее реализован без особых проблем. Следовательно и реализовать названное мной [в общем случае] возможно и не слишком сложно.

EstetsВ общем случае требующий неоправданных затрат на проектирование базовых объектов.
Хм. То есть Вы считаете две тысячи строк неоправданными затратами?

Не знаю. Лично я готов потратить неделю-две, дабы потом год за годом беспроблемно работать.

EstetsНастолько неоправданных что я не знаю известных программ, библиотек или средств разработки реализующих данный принцип.
Хм. Какой именно принцип? И если на то пошло, какие Вы знаете? :)

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

EstetsНет действительно если для работы с ORACLE достаточно "Открыл транзакцию - загрузил документ - поправил - нажал ОК commit/нажал Cancel rollback. ;)", то я первый побегу с требованием к разработчикам сменить БД ;)
Хм. Так бегите :)

EstetsКак говорил классик "Не верю",
Ну, на нет и суда нет. Представлять код, извините, не буду - в первую очередь потому, что он принадлежит не мне.

EstetsЕсли упростить до предела "Нельзя создать связанную запись до тех пор пока главная запись физически не сохранена в базе".
Хм. Что-то я перестал Вас понимать. Я тоже не знаю библиотек, реализующих столь идиотский принцип, и не понимаю, откуда Вы его вытащили. Если же говорить о принципе "нельзя сохранить связанную запись, пока главная не сохранена", то он называется FOREIGN KEYем, и построенных на его учете библиотек, назовем так, много :)

EstetsИз чего следует ;) что не существует промышленных систем реализующих в полном объеме как вы сказали "cached updates" обновление информации для документов MASTER-DETAIL.
Хм. Меня учили, что из изначально..... нелогичного утверждения может следовать все что угодно, и это ровным счетом ничего не значит.

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

EstetsА - возможно только для ORACLE
Скорее для любого версионника.

EstetsБ - возможно для версионника и для блокировочника, но в сложных случаях ИМХО не реализуемый
Ну - как говорится, если факты противоречат теории, тем хуже для фактов.

EstetsВ - способ известный еще со времен DBASE, имеет право на жизнь,
Не имеет. При встрече убивать вместе с автором.

EstetsГ. - предложенный мной способ решения, имеющий свои особенности.
Вот этот я бы классифицировал как "имеет право на жизнь".

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

EstetsТак это все таки заслуга Oracle без его блокировки ресурсов при изменении данных или ваша?
Хм. Ну во-первых формулировка крайне неудачна, во-вторых - заслуга Oracle.

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

EstetsА по поводу возможности реализовать алгоритм "Б", я не говорил что это невозможно, я и сам часто такой подход использовал, но полностью построить систему по такому принципу у меня мозгов и времени не хватило ;)
Мы с Вами упорно не понимаем друг друга. Я не понимаю, какие мозги и время нужны для "полного построения по такому принципу" в сравнении с "частичным построением". Механика закладывается один раз, в базовых классах, а дальше формы пользуются этой функциональностью на уровне настройки, на уровне "включил использование фичи".

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

EstetsМожет быть это и выход, но у нас такой возможности не было. Логика была только на сервере и соответственно закладывалась в момент компиляции процедуры или работала по настройкам, которые выполнялись скопом и вмешаться в процесс выполнения было нельзя.
Хм. А в MSSQL-е отсутствует динамический SQL?

Боюсь, у меня недостаточно знаний системы прав MSSQL, чтобы оценить Ваш ответ.

Что ж (пожимая плечами) быть по сему. Значит нельзя.