vmagТак, на всякий случай - в моем варианте физически нельзя получить одну и ту же заявку более чем одному юзеру, это реализовано на уровне схемы БД...

Так MrShin пишет про кэши, на уровне схем то все ОК, но если кэш не залился в сеть, то схема ни схема а другой юзер не видит этих данных, или я ошибаюсь?

Я попробую сегодня/завтра протестировать твой вариант)

vmag- Проверка перед захватом тоже прямо в таблице (кинжальная)
Как же, акс ведь из кеша может дернуть эту инфу, я такое наблюдал...
а потом он тупо запустит запрос на изменение, который не позарится на внесенные недавно изменения, вот это и генерирует проблему...

vmagпожалуйста отпишитесь о результате, для меня это тоже важно

Сегодня и завтра не выйдет потестить, только в ПН.
Сейчас все подготовлю для этого.

MrShin,

Вопросы появились:

Если я выключу транзакции в запросе к одной таблице, чем я рискую? По логике вещей - ничем, верно? Там идет обновление 3-х записей в одной таблице. Риск потери данных из-за выключения компа точно такой же, как и при завершении транзакций, верно?

Про 100 милисекунд - как на практике происходит соревнование за доступ к ресурсу? Жесткий диск разве сам не выстраивает очередь? Один юзер получит доступ, а другой получит отказ и повторит попытку только через следующие 100 милисекунд, верно?

MrShinВ общем, в вашем случае я бы не особо заморачивался с многопользовательскими штучками, т.к. вероятность того, что ваши 3 несчастных пользователя нажмут кнопку одновременно ничтожно мала. Они нужны, когда автоматические процессы меняют тысячи записей подряд, и действуют несколько таких процессов одновременно. В этом случае вероятность коллизий резко возрастает. А для такого рода задач я бы Акцесс не выбрал, для этого есть серверные базы данных.

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

Я до последнего отказываюсь от VBA, мне в 99 из 100 случаев достаточно штатных макросов, что позволяет избежать потребности в безусловном разрешении выполнения всех кодов VBA. Раньше я каждый чих пытался прописать в VBA, но когда понял, что в аксе лучше ничего серьезного даже не проектировать, то ушел от этой концепции, и зачастую оказывается, что есть более оптимальные решения и без VBA, просто не хватает знаний возможностей приложения.

Транзакции по умолчанию включены во всех запросах (созданных через конструктор) акса. И как я понял, при выполнении макроса, акс открывает транзакцию и только после его завершения закрывает ее. а у меня там прилично запросов подряд выполянется, сначала резервируется клиент, а потом дописываются данные в связанные таблицы (подтягивается список услуг, информация по речевому модулю и всякая мелочь) - видимо все это идет в рамках одной транзакции... А когда еще и форма открывается (также из штатного макроса) то транзакция видимо вообще закрывается после закрытия формы, соответственно только тогда и происходит отложенная запись изменений. Такие выводы делаю из-за очень частых конфликтов (я тоже считаю что вероятность в один момент направить запрос к БД крайне мала, там ведь даже не секундами считается). Сейчас выключил в ключевых запросах транзакцию, буду пробовать так... Если и это не поможет, то напишу логику на VBA.

Конечно, я ждал такой реакции, хорошо еще фото помидора не прикрепили :)
Все, что я ниже написал - это моя призма.

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

Но когда на форуме поднимаются темы, типа: "Как выполнить несколько запросов подряд", "как посчитать количество рабочих дней", "как обратиться к элементу подчиненной-подчиненной формы" и первые советы сразу из VBA.
Хотя для всего этого у акса уже есть инструменты, не требующие VBA, но мы их не изучаем, потому что проще на VBA.

vmagТут как-то кажется DB. (могу ошибаться) сказал: на акцессе можно реализовать всё, ну по крайней мере - почти всё... естественно, вне VBA эта фраза теряет всякий смысл...

Конечно. Даже больше. Если заменить в фразе Access на Excel, то утверждение также останется верным!

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

И что на счет параметров безопасности? Представляете какая дыра появляется, когда разрешаешь выполнять все VBA-макросы без подтверждения? Ведь на VBA можно сделать все! Или нужна подпись, а если есть центр сертификации на корпоративной сетке, то значит где-то есть и MSSQL, зачем вообще тогда Access - максимум - интерфейс к MSSQL (Вот здесь можно, может даже нужно, работать с VBA, чтобы при компиляции скрыть логику)...

Акс отличная песочница, для тех кто хочет получить основы БД, но нельзя на нем строить серьезные решения. А раз нельзя, то зачем сразу все усложнять в VBA? Вот хорошая фраза:

Закон МейераУсложнять — просто , упрощать — сложно
Стоит тебе уйти с рабочего места, как твои плоды сразу прекращают обслуживаться - в VBA никто разбираться не будет, развития решение получать не будет. Будут либо тебя дергать, либо откажутся от твоего решения. А подключать нового человека из вне - вопрос доверия. Чем проще решение на выходе - тем лучше.

Лично мое использование акса сводится к автоматизации повторяющихся запросов и создания форм ввода данных, и лишь для этого VBA явно не нужен.

хм-м-м,

да здесь же о другом.
Все кто мутит решения в аксе - это мы, здесь и общаемся.

А на работе такие решения появляются в двух случаях:
1. Сотрудник разбирается в аксе - таких единицы;
2. Заказчик (директор/начальник) нашел доверенного фрилансера;

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

А если решение написано на VBA, то встает вопрос о читаемости кода, здесь заказчик редко предъявляет требования. А с не читаемым кодом кто будет работать?

Ушли от темы... прошу прощения.

vmag,

Протестировали мы.
Выбрали юзеров и по команде нажали на кнопки.
У обоих в списках задач появилась эта задача.
Конечно после следующего requery список задач в работе обновится, но как бы на это надо давать таймер и повторять запрос.

Я реализовал без VBA эту тему.
Запрос на бронирование очереди сделал с выборкой на 3 записи.
Таким образом резервируется 3 записи вперед.
И каждый раз при выборе нового задания система отбирает 3 записи, еще не отработанные сотрудником, включая ранее им зарезервированные. Т.е. добавляется одна новая запись - на ней ставится резервация.

Вот запрос на выборку:



И запрос на обновление:


Здесь видно, что сначала в работу попадают задачи, зарезервированные раньше остальных.

Конфликты остались, но они происходят в задачах до которых юзер еще не дошел, и у него есть 2 задания в запасе для нивелирования конфликта.

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

Единственный возможный явный конфликт - если при старте системы все одновременно начнут работать - здесь я создал форму-прелоадер, которая по таймеру (раз в 2 сек) проверяет успешно ли записались данные - это окно вываливается единожды при начале работы. Стресс тест не выдал конфликтов.

В целом стало даже быстрее работать.

Толикmanvmag,

Протестировали мы.
Выбрали юзеров и по команде нажали на кнопки.
У обоих в списках задач появилась эта задача.
Конечно после следующего requery список задач в работе обновится, но как бы на это надо давать таймер и повторять запрос.


Забыл написать, в том сообщении приложен твой файл БД (сразу после конфликта) и скриншоты с двух ПК.

vmag,

Так можно придумать собственную логику блокировки записей)

Мы здесь же отбрасываем вариант с использованием серверной БД, запрос был - как решить в Аксе.

Вариант с назначением диспетчера вполне актуальный, но:

1. Придется запускать отдельный файл на чьей то машине, и контролировать факт его работы. При этом этот диспетчер должен видимо каждую секунду/три распределять очередь. Ведь если появится новый сотрудник, он же не должен ждать минуту-две пока этот диспетчер очнется с очередной иттерацией. А частые запросы - это все таки нагрузка. Да может потребоваться отдельная машина, ну как минимум отдельный экземпляр.

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


Вариант с использованием файлов:

1. Дублирует логику самого акса, костыль еще тот. Писать в файл - это подключать API насколько я помню, это достаточно серьезные интеллектуальные вложения, по-моему... Конечно сейчас все копируется. Но все же.

2. какие еще подводные камни? Пока идет запись, другие могут только ждать. Работа с файловой системой влечет дополнительные сетевые ресурсы, там же каждый раз проверяется используется ли файл другим или нет, и это может порождать задержки, а если мы будем постоянно опрашивать, пока файл не будет удален, то эти задержки кратно растут.


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

И вариант с резервированием на несколько задач вперед вполне подошел.
Я выключил транзакции, блокировку оставил на уровне страниц, и получил решение с постоянным доступом к данным.
С точки зрения пользователя все работает.
С точки зрения решения, происходит управление конфликтами (они просто предусмотрены).
Нет задержек из-за блокировок, нет нагрузки на сеть по секундам (единственная нагрузка - раз в 5 минут обновляется сессия по сотрудникам с каждого клиента), нет тормозов в интерфейсе.

Думаю что это оптимальное решение.
Не требует сложной логики на VBA, т.е. можно реализовать штатными средствами (Макросами), можно простыми командами VBA.
Достаточно продумать логику двух запросов - на выборку и обновление.

Кстати кому интересны наблюдения за макросами:
Пока непрерывно выполняется макрос - блокировка не снимается, и если в конце макроса открывается форма - блокировка связанных с формой таблиц может сохраниться.

Чтобы блокировки с таблиц снялись надо сделать перерыв, причем это зависит от скорости работы машины, на домашнем ПК с SSD мне 250 миллисекунд было недостаточно, а 300 уже достаточно, на рабочем с сеткой это значение приблизилось к 450/500.

Прерывание можно делать формой с таймером управляя событиями "Открытие" и "Таймер", при этом останавливать сам макрос не обязательно, достаточно открыть форму в режиме диалогового окна.

Надеюсь кому-нибудь данный опыт поможет.