При работе в многопользовательском режиме с файловой базой 1С:Предприятие 8 через сетевой ресурс часто возникают ситуации, когда после успешного обновления конфигурации один пользователь видит корректный результат, а другой сталкивается с повторными запросами системы. Рассмотрим ситуацию: база Бухгалтерия предприятия 2.0 обновлена до последнего релиза, первый пользователь зашел, подтвердил легальность использования, и программа работает штатно. Однако при входе второго пользователя снова появляется окно подтверждения, будто обновление не проводилось или данные о нем не сохранились в базе. Разберем причины этого поведения и способы решения проблемы.
Для начала проанализируем, что происходит в системе в момент подтверждения легальности. Когда первый пользователь нажимает кнопку подтверждения, программа записывает соответствующий признак в информационную базу. В старых редакциях, таких как БП 2.0, этот механизм может быть завязан на определенные параметры сессии и файлы блокировок. Если второй пользователь видит запрос повторно, это означает, что его сессия "не видит" изменений, внесенных первым пользователем, либо система интерпретирует его вход как требующий новой проверки.
Выясним, отображаются ли оба пользователя в списке активных. Для этого воспользуемся консолью кластера (если бы это был серверный вариант) или просто проверим наличие файла блокировок 1Cv8.cdn в папке с базой. Также обязательно заглянем в ЖурналРегистрации. Нам нужно проверить, зафиксированы ли там события обновления для первого пользователя и видны ли попытки входа второго. Если действия первого пользователя видны, а второй пользователь получает ошибку или запрос сразу после входа, значит, проблема кроется в локальном окружении или правах доступа.
Самая распространенная причина некорректного отображения статусов в 1С — это локальный кэш конфигурации. Программа кэширует метаданные и служебную информацию для ускорения работы. Если у второго пользователя сохранился старый кэш, он может обращаться к устаревшим формам и алгоритмам проверки. Разберем, как правильно очистить кэш у второго пользователя:
%AppData%\1C\1cv8%LocalAppData%\1C\1cv8eb652d88-8888-466d-a773...).Важно помнить, что в БП 2.0 (на обычных формах) кэш играет огромную роль в правильном функционировании логики обновления. Если очистка папок вручную не помогает, попробуйте удалить информационную базу из списка в стартере и добавить её заново. Это гарантированно создаст новый идентификатор и новую папку кэша.
Хотя в редакции 2.0 механизмы обновления проще, чем в 3.0, всё же стоит убедиться, что все процедуры завершены. Проанализируем ситуацию: если в базе предусмотрены какие-либо пост-обновляемые действия, они должны выполниться под первым пользователем монопольно. Убедимся, что первый пользователь не просто зашел в базу, а дождался окончания всех фоновых процессов (если они есть) и закрыл все системные сообщения.
В некоторых случаях признак Легальность получения обновления подтверждена может записываться не в общие константы, а проверяться через внешние компоненты или файлы в профиле пользователя Windows. Если настройки профиля повреждены, 1С не может корректно прочитать или записать флаг проверки.
Поскольку база файловая и находится в сети, огромную роль играют права доступа к файловой системе NTFS и настройки протокола SMB. Рассмотрим подробнее механизм "Opportunistic Locking" (oplocks). Если этот механизм включен на сервере или клиентском ПК, Windows может кэшировать изменения файлов в памяти, не записывая их на диск мгновенно. В результате второй пользователь видит "старую" версию файла 1Cv8.1cd, где флаг подтверждения легальности еще не установлен.
Проверим права доступа. У второго пользователя должны быть полные права (Чтение, Запись, Изменение) на всю папку с базой данных, а не только на файл 1cd. Если прав на создание временных файлов (например, файлов блокировок или временных таблиц в папке базы) недостаточно, процедура проверки легальности может завершаться сбоем, который визуально выглядит как повторное окно запроса.
Проанализируем ситуацию с виртуализацией папок. Если папка с информационной базой находится в защищенном месте (например, внутри C:\Program Files), Windows включает механизм VirtualStore. В этом случае, когда первый пользователь "вносит изменения" в базу, физически они могут записываться в его личный профиль: C:\Users\ИмяПользователя1\AppData\Local\VirtualStore\.... Второй пользователь, заходя в базу, обращается к оригинальному файлу в Program Files, который остался нетронутым.
Рекомендация: Никогда не размещайте файловые базы 1С в системных папках Windows. Перенесите базу в корень диска (например, D:\1C_Bases) и настройте общий доступ с полными правами для всех пользователей группы "Пользователи" или конкретных учетных записей.
Как показывает практика и разбор конкретных случаев на форумах, если очистка кэша и проверка прав не помогают, причина может крыться в повреждении настроек пользователя Windows. В 1С:Бухгалтерия 2.0 некоторые параметры сеанса и настройки защиты могут быть жестко привязаны к идентификатору пользователя SID или путям в реестре HKEY_CURRENT_USER.
Если у пользователя "слетели" настройки профиля (например, после сбоя домена или обновления ОС), 1С может воспринимать каждый запуск как "первый раз". В этом случае помогает:
Разберем, как использовать ЖурналРегистрации для локализации ошибки. Откроем его под правами администратора и установим фильтр по пользователю, у которого возникает проблема. Ищем события с уровнем Ошибка или Предупреждение. Особое внимание уделим событиям:
Доступ.Отказ в доступеИнформационная база.Изменение параметров
Если мы видим, что при входе второго пользователя система пытается записать данные в таблицу Config или служебные константы и получает отказ, значит, проблема в сетевых правах. Если же событий записи вообще нет, а система сразу переходит к выводу формы подтверждения — проблема в том, как платформа интерпретирует текущую сессию пользователя.
Посмотрим на пример того, как можно программно проверить статус обновления через консоль запросов (для программистов), чтобы убедиться, что значение в базе действительно изменилось:
ВЫБРАТЬ
Константы.ПодтверждениеЛегальностиПолученияОбновлений КАК Статус
ИЗ
Константы КАК Константы
Если запрос возвращает Истина, а окно всё равно появляется, значит, дело в платформенных механизмах кэширования или специфике работы БП 2.0 с конкретным профилем Windows.
Подводя итог, если вы столкнулись с бесконечным окном подтверждения легальности в БП 2.0 у второго пользователя, выполните следующие шаги:
Выяснение причины через системные журналы и проверку сетевой прозрачности поможет быстро вернуть систему в рабочее состояние и избежать повторных запросов легальности.