В практике администрирования 1С встречается загадочная ситуация: пользователь работает в системе, создает документы, но его нет в списке активных сеансов, его действия не фиксируются в журнале регистрации, а при записи документов возникают ошибки уникальности номера. При этом проблема проявляется только при определенном способе подключения, например, через удаленный рабочий стол (RDP).
Рассмотрим подробно причины возникновения этой «параллельной реальности» и разберем по шагам, как выявить и устранить технические неполадки, приводящие к подобным симптомам.
Самая распространенная причина, как показал разбор ситуации на форуме, — это банальное подключение пользователя к другой информационной базе или другому кластеру серверов. Даже если визуально интерфейсы идентичны, данные могут записываться в разные места.
Проанализируем, как это происходит. На сервере терминалов (RDP) список баз пользователя может быть настроен иначе, чем на его локальном компьютере. Если одна и та же база данных (на уровне СУБД) зарегистрирована в двух разных кластерах 1С (например, основной и тестовый), возникают следующие конфликты:
srvinfo. Проверяя журнал в основной базе, мы не увидим действий пользователя, работающего через «соседний» кластер.Для диагностики этой проблемы выполним следующие действия:
Srvr="MainServer";Ref="Trade_Base";
и сравним её с настройками на рабочем месте, где всё работает корректно.MainServer:1641 вместо стандартного 1541, это явный признак работы с другим экземпляром службы сервера 1С.Выясним, почему при «раздвоении» кластеров возникают именно ошибки нумерации. В платформе 1С 8.3 реализован механизм автоматического получения номера с предварительным кэшированием.
Рассмотрим подробнее работу этого механизма: для ускорения работы сервер 1С (процесс rphost) запрашивает у системы блок номеров (например, 10 штук вперед). Когда пользователь нажимает «Создать», номер берется из этого локального кэша. Если у нас запущено два независимых кластера, каждый из них может захватить один и тот же диапазон (например, номера с 100 по 110). Ошибка возникнет только в момент попытки записи (метод Записать()), когда СУБД отклонит транзакцию из-за нарушения уникальности поля Number.
Бывают случаи, когда строка подключения в 1С выглядит абсолютно идентично, но физически запросы уходят на разные серверы. Проанализируем ситуацию с разрешением имен.
На сервере терминалов системный администратор мог внести правки в файл hosts по адресу C:\Windows\System32\drivers\etc\hosts. Если там прописано статическое соответствие имени сервера 1С другому IP-адресу, пользователь попадет не туда, куда ожидалось.
Для проверки выполним команду в консоли cmd на сервере RDP:
ping ИмяСервера1С
Сравним полученный IP-адрес с адресом, который выдает та же команда на локальном компьютере пользователя. Если адреса разные — проблема в сетевых настройках или DNS.
Если с подключением всё в порядке, но записи в журнале регистрации всё равно отсутствуют, стоит обратить внимание на техническое состояние файлов журнала. Начиная с версии 8.3.5, 1С может использовать новый формат журнала — .lgd (база данных SQLite).
Посмотрим на возможные проблемы этого формата:
rphost пытаются одновременно писать в один файл 1Cv8.lgd. SQLite — файловая база, и она крайне чувствительна к таким блокировкам. Один из процессов может просто «молча» перестать писать логи, столкнувшись с постоянной занятостью файла.USR1CV8). У этой учетки должны быть полные права на папку srvinfo. При работе через RDP иногда задействуются специфические настройки профиля, которые могут ограничивать запись в определенные сетевые каталоги.Проанализируем еще один редкий, но возможный сценарий: на сервере терминалов установлена версия платформы (например, 8.3.22.1704), которая отличается от версии, установленной непосредственно на сервере 1С (например, 8.3.22.1709).
В некоторых конфигурациях это позволяет войти в базу, но вызывает нештатное поведение. Разберем, к чему это приводит: компоненты клиента и сервера обмениваются данными по определенному протоколу. Разница в релизах может приводить к тому, что пакеты с событиями журнала регистрации просто не доходят до сервера или некорректно обрабатываются менеджером кластера.
Для окончательного устранения проблемы рекомендуется придерживаться следующего плана действий:
Srvr и Ref в окне запуска 1С.
%AppData%\1C\1Cv8
%LocalAppData%\1C\1Cv8
1Cv8Log) файлы журнала доступны для записи пользователю, от имени которого работает служба 1C:Enterprise Server.
// Пример программного изменения номера для восстановления очереди
ОбъектДок = ДокументОбъект.ПолучитьОбъект();
ОбъектДок.УстановитьНовыйНомер("ПРЕФИКС");
ОбъектДок.Записать();
Важно помнить: Порядок в справочнике «Информационные базы» у пользователя — это залог корректной работы системы. Ситуация, когда «админы ничего не меняли, оно само», часто скрывает под собой создание тестовых копий или перенос баз между кластерами без удаления старых регистраций. Всегда начинайте диагностику с проверки того, в какой именно физической базе находится пользователь в данный момент.