Что будет если пользователи одновременно добавят запись в БД?

[Dux]

БД - Access, доступ через ADOQuery. Ключевое поле в базе данных - счетчик.

Вопрос, если несколько пользователей одновременно добавят запись - как на это будет реагировать Access? Получится две записи с одинаковым номером в ключевом поле?

[Stilet]

Одновременно не смогут. Сначала будет одобрена первая транзакция - ей дастся свободный IDшник (если он автоинкрементный), потом только пойдет вторая.
Все равно разбор полетов будет последовательный - кто первый тот и папа )

[Dux]

Сообщение от Stilet

Одновременно не смогут. Сначала будет одобрена первая транзакция - ей дастся свободный IDшник (если он автоинкрементный), потом только пойдет вторая.
Все равно разбор полетов будет последовательный - кто первый тот и папа )

Т.е. на этот счет можно не заморачиваться..?

Stilet - подскажите, вы не в курсе, почему народ на Access грешит? могут возникнуть проблемы при многопользовательском доступе?

[Stilet]

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

[Sciv]

могут возникнуть проблемы при многопользовательском доступе?

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

[Stilet]

два пользователя открыли запись, никто сохранить не может, пока один из них не выйдет. Ибо для чтения открыта, а для записи - заблокирована.

Ты удивишся, но это во всех СУБД есть. Называется механизм Deadlock. Это нормально для любой уважающей себя системы, так что не наговаривай на Ассекс

P.S. Кстати про дедлоки у Тома Кайта хорошо написано, можете почитать (не смотря на то что пишет он про Оракл, его литература заслуживает внимания)

[Dux]

Сообщение от Stilet

Задача какая стоит?

На сервере лежит база. 5 операторов, время от времени заходят, редактируют. + 2 менеджера - в режиме readonly

[Sciv]

Ты удивишся, но это во всех СУБД есть. Называется механизм Deadlock.

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

За Тома Кайта отдельное спасибо, пошел качать.

[Stilet]

что даже для чтения может открыть только один юзер, второму будет выдано что-то типа "Запись заблокирована". Нет?

Не всегда. Что-то есть в SQL типа инструкции exclusive (не помню точно, книгу надо открывать...), которая запрещает доступ к набору, открытому одним пользователем (позаписно, постранично, потаблично и т.д. - читай Кайта, там написано).
как Аксекс действует не скажу, но не факт что он такие фокусы устроит, хотя не поручусь.

На сервере лежит база.

Расшарена папка на запись, я так понимаю?
проблема тут у тебя еще одна появляется - расшаренные на запись каталоги - дыра в безопасности. Это впрочем еще один гвоздь в гроб локальных СУБД, тут не поспоришь, гики аж захлебываются, когда у них появляется возможность уличить в этом.
Если не критично я бы на твоем месте выбрал другую СУБД.
Я кста использую MS SQL Express. его можно неплохо защитить, и он многопользовательский. Работает лучше и стабильнее, удобнее настраивать чем Акцесс. По умолчанию в винде для него есть провайдер, так же как и для Акцесса (А даже через ODBC можно подключение настроить - обычно так и делают, удобнее получается). Работать с ним так же через ADO. К тому же Сиквел лучше равивается с отличии от акцесса.

[Dux]

Спасибо за комментарии.. пока попробую продолжить с Access. Дальше видно будет.