Господа! Поправтье меня, если я не прав.

Если мы работаем с удалённой БД через DataAdapter, то:
1. Коннект открывается
2. Данные загружаются
3. Коннект закрывается
4. Данные меняются
5. Коннект открывается
6. Данные загружаются обратно
7. Коннект закрывается

А если я открыл приложение и начал работать с загруженными данными. В это время Вася Пупкин открыл то же самое приложение с теми же самыми данными. Потом он изменил данные и записал их в базу(а я ещё работаю). В этот момент у меня данные неактуальны. Легко представить себе ситуацию, когда это упадёт!!!

Я прав? И если я прав, то как этого можно избежать?

Есть разные виды блокировок - опитмистическая и пессимистическая.
Оптимистическая - это как раз то, что ты имеешь. Кто последний сделал изменения - тот и прав
Пессимистическая - это ты вытаскиваешь данные и на это время их блокируешь от изменений. Тогда пока ты не снимешь блокировку читать другим еще можно, а вот записать нельзя.

Надо смотреть как это может быть реализовано прямо на SQL.

1. Оптимстическая
А если я пытаюсь сделать update удалённой записи? Получается кто первый - тот и прав....
2. Пессимистическая
Здесь у нас на фирме возникли идеи след. толка - семафоры или некая прослойка между клиентом и БД, которая отвечает за подобную байду! Но как то гнило всё это... Есть какие-нибудь идеи как это реалзовать. Пример MS SQL 2000/// Так же интересно для Oracle...

Цитата(Feliastre @ 4.2.2005, 02:59)

А если я пытаюсь сделать update удалённой записи? Получается кто первый - тот и прав....

Чтобы исправить ситуацию есть 4 способа (при оптимистической блокировке)
1. Вообще забыть про все и обновлять через примари ключ. Тут ни один из юзеров не может быть уверен что именно его изменения сейчас сидят в ДБ

2. Менять указывая не только ключ, но и ВСЕ поля.

Код

UPDATE Customers SET CustomerName="Pupkin" WHERE CustomeID='33' AND CustomerName="Gorkiy" AND CustomerJob='Writer'

Тогда если кто-то до тебя поменял CustomerJob то данный запрос не выполнится и выдаст ошибку

3. Аналогичный способ, только вместо указания всех полей в ДБ добавляется столбец timestamp который сначала у всех рядов одинаков. При изменении ряда сервер его меняет и следующий юзер, если попытается изменить старую запись получит ошибку.

Код

UPDATE Customers SET CustomerName="Pupkin" WHERE CustomeID='33' AND ТimeStampColumn='0000000001'

Если ТimeStampColumn уже 0000000002, то этот запрос не пройдет.

4. Менять, указывая в WHERE только те поля, которые ты изменил. Это то же самое, что и способ 2, но чуть экономнее, хотя предполагает дополнительную логику.

Domestic Cat Не понял... Любой из этих апдейтов рухнет если данное поле было удалено...

Ну так в том и суть.