Доброго времени суток.

Имеется:
1. Двухзвенное приложение (Клиент на C# 3.5 framework, BD: MS SQL 2005).
2. Проблемы с многопользовательским режимом работы с данными. Когда пользователи работают с одними и теми же данными с разных рабочих мест.
3. Самописная ORM библиотека.
4. Очень сложная БЛ на стороне клиента с кэшированными данными, полученными с БД.
5. ТЗ на проект нет, где бы описывалась многопользовательская работа с данными.

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

Например одна из многих проблем: что делать, если два пользователя с разных компьютеров параллельно загрузили какой нибудь корневой бизнес объект с БД, который загружает по иерархии много других сущностей в. Один пользователь удаляет корневой объект, который каскадно удаляет нижелещую архитектуру. Другой пользователь в это время параллельно работает с кэшированными данными порядка 3-4 часов, потом при попытки сохранить свои изменения неприятно удивляется.
Проблемных сценариев достаточно много...

Поделитесь опытом кто сталкивался с такими проблемами. Какие подходы к решению данных проблем предпринимали?

Petro123LameUser3. Самописная ORM библиотека.

за сабжем следит ОРМ, если он есть .
Значит выкинуть или взять готовый

А могли бы вы поконкретнее описать сам процесс "слежения"? В чем он заключается?
Был бы признателен, если бы вы дали какую-нибудь ссылку на конкретную информацию.

LSVРасшифруйте п. 2
Сидят двое и колбасят в одном документе (не подозревая об этом) ?

У нас ведется таблица занятых документов. Тот кто зайдет в д-т вторым, получит оповещение и режим ридонли.
Есть возможность отправить оповещение первому юзеру "мол отпусти, а ?".
Специальная логика следит, чтоб не возникало "зависших блокировок д-тов" (допустим юзер внезапно отвалился).

Тут нет понятия "отдельного документа".

БЛ приложения настолько сложная, что просто напросто не реализуема на стороне SQL сервера. К примеру один из модулей имеет возможность настройки всего-и-вся. (Создаются справочники пользователя, пользователь сам создает бизнес-сущности, формулы по которым считаются эти бизнес сущности, зависимость сущностей друг от друга (граф))), в формулы расчета сам колбасит ссылки на другие свойства других бизнес объектов приложения, некоторые из таких свойств тоже считаются весьма нетривиальным образом ) Наложено много ограничений и проверок полученных формул на корректность составления. Со стороны сервера это все хранится в древовидной структуре порядка 20 уровней вложенности. Даже если и реализовать на стороне БД - расширяемость такого решения весьма проблематично. А развитие довольно такие бурное. При том пользователь может создавать разные расчеты, которые между собой могут пересекаться общими объектами, а могут и не пересекаться...

Другими словами тут вряд-ли получится спроецировать работу с данными на отдельно взятый документ.
Интересная мысль насчет блокировок данных в БД... Думаю стоит подумать над этим.