Переход с 32-битной на 64-битную платформу 1С:Предприятие — это стандартный шаг при масштабировании системы, однако он часто сопровождается техническими нюансами. Одной из самых неприятных проблем является ситуация, когда после переноса данных в интерфейсе 1С журнал регистрации оказывается пустым, хотя физически файлы журнала присутствуют на диске и даже увеличиваются в размере. Рассмотрим подробно, почему это происходит и как восстановить доступ к историческим данным событий системы.
Первым делом проанализируем, как сервер 1С сопоставляет информационную базу и её журнал регистрации. В серверной версии 1С все логи хранятся в подпапках каталога reg_1541 (путь по умолчанию: C:\Program Files\1cv8\srvinfo). Каждая база имеет свой уникальный идентификатор — GUID. Папка журнала регистрации находится по пути: reg_1541\GUID_вашей_базы\1Cv8Log.
Разберем ситуацию: если при установке новой платформы x64 вы не просто скопировали папку srvinfo, а заново регистрировали базы в консоли администрирования, сервер присвоил им новые GUID. В этом случае сервер создаст новую пустую папку для логов, а старые файлы останутся в папке со старым идентификатором. Выясним актуальный GUID нашей базы, чтобы сопоставить его с именем папки. Для этого в списке баз при запуске 1С выполним следующие действия:
В тексте ссылки после параметра Ref= мы увидим строку формата ID=.... Это и есть актуальный идентификатор. Проанализируем содержимое reg_1541: если имя папки с логами отличается от этого ID, нам необходимо остановить службу сервера 1С и переименовать папку со старым идентификатором под новый, либо перенести файл 1Cv8.lgd (или файлы .lgp) в директорию с актуальным именем.
Начиная с версии платформы 8.3.5, основным форматом журнала регистрации является SQLite (файл 1Cv8.lgd). Проанализируем специфику этого формата при переносе между системами. В отличие от старого текстового формата .lgp, SQLite крайне чувствителен к целостности своих индексов и наличию вспомогательных файлов.
Рассмотрим ситуацию, когда файл 1Cv8.lgd на месте, но данные не отображаются. Это может быть связано с повреждением внутренних индексов базы данных SQLite при некорректном завершении работы старой службы. Для диагностики и исправления попробуем выполнить команду VACUUM. Это стандартная команда SQLite, которая пересобирает файл базы данных, очищая его от "мусора" и восстанавливая индексы. Для этого можно воспользоваться сторонними утилитами, например SQLite Browser. Выполним следующий скрипт внутри утилиты:
-- Проверка целостности файла
PRAGMA integrity_check;
-- Пересборка базы данных для восстановления индексов
VACUUM;
Также важно обратить внимание на файлы 1Cv8.lgd-wal и 1Cv8.lgd-shm. Это временные файлы режима Write-Ahead Logging. Если мы переносим журнал "на горячую" или копируем эти файлы вместе с основным, 1С может считать базу заблокированной. Рекомендуется при выключенном сервере переносить только основной файл 1Cv8.lgd, временные файлы сервер пересоздаст самостоятельно.
Проблема "пустого журнала" часто кроется не в самих данных, а в механизмах их отображения. Проанализируем влияние кэша. В платформе 8.3.10 и выше существуют два вида кэша, которые могут влиять на результат:
snccntx в каталоге описания информационной базы. Мы уже упоминали о её очистке, но важно делать это строго при остановленной службе сервера 1C:Enterprise 8.3 Server Agent.%AppData%\1C\1Cv8).Иногда платформа "запоминает" старые отборы (например, по идентификатору сеанса, которого больше не существует в новой системе), и даже при нажатии кнопки "Установить стандартные настройки" фильтр продолжает скрывать записи. Разберем радикальный, но эффективный способ: удаление папки с настройками пользователя. Пройдем по пути C:\Users\Имя_Пользователя\AppData\Roaming\1C\1Cv8 и удалим папки с длинными буквенно-цифровыми именами. После этого настройки интерфейса сбросятся к заводским, и скрытые записи журнала могут появиться.
При переходе с x32 на x64 устанавливается новая служба. Проанализируем права доступа. По умолчанию служба 64-битного сервера запускается от имени пользователя USRP1CV8 (или аналогичного, созданного при инсталляции).
Выясним причину возможной блокировки: если папка reg_1541 была скопирована из-под учетной записи администратора, у пользователя USRP1CV8 может не быть прав "Полный доступ" (Full Control) на вложенные объекты. В такой ситуации возникает парадокс: сервер может открывать файл на дозапись (поскольку имеет права на папку), но не может считывать сложные выборки через индексы SQLite для отображения в форме. Проверим свойства папки 1Cv8Log, перейдем во вкладку "Безопасность" и убедимся, что учетная запись, под которой работает служба 1C:Enterprise 8.3 Server Agent (x64), имеет полные права на папку и сам файл 1Cv8.lgd.
Если визуально журнал пуст, проверим, "видит" ли его сама платформа программно. Это поможет исключить ошибки интерфейса. Создадим внешнюю обработку и попробуем программно прочитать последние записи. Рассмотрим пример кода для проверки:
Фильтр = Новый Структура;
Фильтр.Вставить("ДатаНачала", НачалоДня(ТекущаяДата()));
ТаблицаСобытий = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(ТаблицаСобытий, Фильтр);
Если ТаблицаСобытий.Количество() > 0 Тогда
Сообщить("Журнал не пуст, найдено записей за сегодня: " + ТаблицаСобытий.Количество());
Иначе
Сообщить("Программное чтение вернуло пустой результат. Проверьте физическое наличие данных.");
КонецЕсли;
Если этот код возвращает количество записей больше нуля, значит, проблема исключительно в кэше настроек формы или поврежденных индексах отображения. Если же результат нулевой — сервер действительно не видит связи с файлом 1Cv8.lgd или файл пуст внутри.
Подводя итог, если вы столкнулись с пустым журналом регистрации после миграции на x64 платформу 8.3.10.2772, следуйте этому алгоритму:
srvinfo. При необходимости переименуйте папку.snccntx в каталоге базы на сервере.USRP1CV8 на файлы журнала.AppData\Roaming.Помните, что формат SQLite более требователен к ресурсам и стабильности, чем старый текстовый формат. В случае критических повреждений файла, когда VACUUM не помогает, единственным выходом может быть создание нового журнала регистрации и использование старого файла только как архивного через внешние инструменты просмотра SQLite.