Здравствуйте Sinclair, Вы писали:

S>Здравствуйте Grog13M, Вы писали:

GM>>Здравствуйте Sinclair, Вы писали:


GM>>>>Как по науке решается вопрос о синхронизации? Может какие-то примеры?
S>>>Главное ключевое слово — ACID (Atomicity, Consisteny, Isolation, Durability). Второе ключевое слово — transaction.
GM>>>>И какую БД лучше использовать для этих нужд?
S>>>Ту, которая поддерживает транзакции. Почти все современные СУБД это делают. Никаких усилий (почти) по синхронизации приложений не потребуется.

GM>>Ага, я понял, принцип транзакции "либо все, либо ничего"
GM>>После того как юзер сделал COMMIT, то любые другие юзеры при SELECT'ах увидят измененное состояние, если СЕЛЕКТ был после КОММИТА и предыдущее состояние если до?
S>Ну, то что на самом деле увидят усеры сильно зависит от так называемого "уровня изоляции" транзакций, в которых они находятся и от используемой модели поддержки кислотности. Например, при дефолтной изоляции (Read Committed) в MS SQL Server усеры, пытающиеся сделать селект по данным, которые сейчас кто-то пишет, будут вынуждены ждать коммита. А вот в interbase, например. они действительно увидят предыдущее состояние.

GM>>Т.е. в самом приложении ничего по синхронизации данных делать не надо? Или?
S>Да. Ничего делать не надо. Прежде всего потому, что дело это дюже сложное, и в стандартные БД встроено более чем достаточно возможностей для поддержки всех типичных сценариев синхронизации.

GM>>Порекомендуйте, пожалуйста, какую-нибудь простенькую БД, с возможностью транзакций.
GM>>Стоять это все будет по Win2000 или WinXP.
S>Гм. Увы, я не спец в этих вопросах. По идее, MS Access должен это все уже уметь — лень читать доку.
S>А так, под виндою, я считаю, лучче MS SQL нету. Тем более теперь он даже в CE варианте есть, то ись совсем нетребовательный зверек.


А скажите, поддерживает ли механизм транзакций такие возможности:

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

Есть ли возможность сообщить юзеру №2, что, хотя он прочел накладную NN, он не имеет право ее редактировать? Есть ли возможность сообщить юзеру №2, кто в данный момент редактирует накладную NN из других пользователей?

Или механизм транзакций может только сообщить юзеру №2 при сохранении накладной, что все изменения, которые он сделал, недействительны, так как данная запись "была изменена другим пользователем"?