Кто получает приоритет доступа, когда 2 пользователя пытаются подключиться? - PullRequest
0 голосов
/ 07 августа 2011

Если 2 пользователя подключаются к Access и запускают запрос, который проверяет последний номер, увеличьте этот номер и вставьте запись в базу данных.

Кто получает приоритет?

Почему я вижудве дубликаты записей с одинаковым номером?

Ответы [ 4 ]

2 голосов
/ 07 августа 2011

Это проблема параллелизма:

И пользователь A, и B считывают текущее значение из базы данных. Затем A увеличивает его на стороне клиента и записывает обратно в базу данных, но B уже прочитал значение и не знает об увеличенном значении. Как и раньше, B увеличивает значение и записывает его обратно, перезаписывая изменения A тем же номером.

Этот тип генерации уникальных номеров небезопасен. Вы должны позволить базе данных делать приращение, используя значение автоинкремента.

В качестве альтернативы вы можете иметь следующую конструкцию:

  • Создать дополнительную таблицу идентификаторов.
  • Создать хранимую процедуру, в которой вы
    • Блокировка доступа к таблице идентификаторов
    • Считать текущее значение
    • Увеличивать и записывать обратно
    • разблокировать доступ
    • Возвращает увеличенное значение

Создание таблицы идентификаторов предотвратит блокировку таблицы данных.

1 голос
/ 07 августа 2011

Ни один из них не получил «приоритет». Это больше не является полезным термином, когда вы говорите о неатомарных операциях. Пример проиллюстрирует проблему здесь.

Вот как выглядит ваш скрипт:

  • Чтение значения из базы данных.
  • Увеличение на 1.
  • Запись нового значения в базу данных.

Это работает, когда только один человек использует базу данных одновременно. Когда больше чем один человек делает, вещи не будут работать. Вот что происходит сейчас:

  • Исходное значение в БД - "100".
  • Клиент A читает «100».
  • Клиент A локально увеличивает «100» до «101», но еще не записал его.
  • Клиент B читает «100».
  • Клиент B локально увеличивает "100" до "101", но еще не записал его.
  • Клиент A пишет "101".
  • Клиент B пишет "101".

Это называется состояние гонки , и это происходит потому, что вы не использовали транзакцию . Вот что может произойти с транзакцией:

  • Исходное значение в БД - "100".
  • Клиент A начинает транзакцию с этим значением.
  • Клиент A читает "100".
  • Клиент A увеличивает локально «100» до «101», но еще не записал его.
  • Клиент B пытается начать транзакцию, но уже существует ожидающая транзакция, поэтому он еще не может начаться.
  • Клиент A пишет "101".
  • Клиент A закрывает транзакцию, и значение фактически записывается.
  • Клиент B начинает транзакцию с этим значением.
  • Клиент B читает «101».
  • Клиент B локально увеличивает «101» до «102», но еще не записал его.
  • Клиент B пишет "102".
  • Клиент B закрывает транзакцию, и значение фактически записывается.
0 голосов
/ 08 августа 2011

Это часто задаваемый вопрос Access.Если вы воспользуетесь Google «Доступ к многопользовательскому пользовательскому счетчику», вы получите целый ряд решений.

Они обычно основаны на использовании таблицы для хранения «начального» значения, которое редактируется исключительно так, чтобы только одноПользователь одновременно может изменить это начальное значение.Могут быть и другие подходы, использующие транзакции Jet / ACE, но этот метод намного проще.

Обратите внимание, что два из трех решений от MS используют ADO, что не рекомендуется в Access, но, вероятно, подходит извне Access.

0 голосов
/ 07 августа 2011

Итак, исходя из последнего вопроса в вашем вопросе, причина, по которой вы видите две записи с одинаковыми номерами, заключается в том, что вы допускаете это в своей схеме / базе данных / таблице для начала.Начните с добавления ограничений и отношений в вашу базу данных, и ваш сценарий выдаст ошибку вместо этого, и вы можете использовать оптимистичный параллелизм для начала со стороны клиента и / или продолжить генерацию уникального ключа на стороне базы данных и / или использовать транзакции ии так далее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...