Представим ситуацию: вы создаете абсолютно чистую базу на сервере 1С, загружаете в нее только конфигурацию (cf-файл), выполняете первичную настройку и уходите. Спустя время вы обнаруживаете, что в базе появились справочники (организации, подразделения, банковские счета) из совершенно другой информационной базы. При этом журнал регистрации утверждает, что эти данные добавили именно вы, причем записи о добавлении одного и того же объекта дублируются с интервалом в час. Разберем эту детективную ситуацию по шагам и выясним, какие механизмы платформы и конфигурации могут приводить к таким «чудесам».
Первое, что приходит в голову при виде «самозаполнившихся» справочников — это работа встроенных механизмов конфигурации. В современных отраслевых решениях, особенно построенных на базе Библиотеки стандартных подсистем (БСП), процесс «первого запуска» включает в себя множество скрытых операций. Рассмотрим подробнее, как данные могли попасть в базу без вашего явного участия.
1. Обработчики обновления и инициализации. При первом запуске системы после загрузки конфигурации всегда срабатывают процедуры обновления информационной базы. Если в коде прописана логика заполнения предопределенных или обязательных данных, система создаст их программно. В вашем случае данные соответствуют другой базе-донору. Это может происходить, если в коде зашит поиск «эталонной» базы в текущем кластере серверов или обращение к внешним источникам по умолчанию.
2. Использование COM-соединений и HTTP-запросов. Проанализируем программный код на наличие методов Новый COMОбъект или Новый HTTPЗапрос. Некоторые конфигурации при отсутствии данных пытаются найти их в соседних базах того же кластера или через веб-сервисы, используя текущую учетную запись Windows. Для диагностики стоит выполнить глобальный поиск по конфигурации (включая расширения):
// Пример поиска инициализации внешних соединений
РезультатПоиска = Конфигурация.Найти("Новый COMОбъект");
РезультатПоиска = Конфигурация.Найти("HTTPЗапрос");
3. Скрытые планы обмена и регламентные задания. Даже если вы не настраивали обмены вручную, они могут быть заложены на уровне поставщика. Проверьте список регламентных заданий сразу после создания базы. Особое внимание уделите заданиям, связанным с синхронизацией данных или загрузкой классификаторов. Если в коде задания жестко прописан путь к файлу или базе (хардкод), система начнет загрузку сразу после старта планировщика.
Ситуация, когда в ЖР отображается два события Данные.Добавление для одного и того же объекта (с одной и той же ссылкой), кажется невозможной с точки зрения логики базы данных. Однако в версии платформы 8.3.12 и выше, где используется новый формат журнала регистрации (.lgd на базе SQLite), этому есть технические объяснения.
Рассмотрим причину «склейки» логов. Платформа идентифицирует информационную базу не только по имени в консоли, но и по внутреннему уникальному идентификатору (UID). Если вы создали новую базу на месте старой (удаленной), и при этом файлы в каталоге srvinfo (на сервере приложений 1С) не были очищены вручную, может возникнуть конфликт. Новая база может начать записывать события в старый файл журнала регистрации, который остался от предыдущей базы с тем же UID. В этом случае вы видите в ЖР «призраков» прошлого — записи, которые физически относятся к другому периоду жизни серверного окружения.
Проанализируем транзакционный кэш. В платформе 8.3.12 была замечена особенность работы ЖР в режиме тонкого клиента. Если запись объекта инициируется программно внутри длительной транзакции, событие добавления может быть зафиксировано в логе в момент начала операции. Если затем произошел сбой сети или «тихий» откат транзакции без закрытия сеанса, повторная попытка записи (инициированная платформой автоматически) может создать вторую запись в ЖР. Выясним причину временного разрыва в 52 минуты: скорее всего, это связано с таймаутом сеанса или регламентным перезапуском рабочих процессов сервера.
Иногда причина кроется не в коде, а в инфраструктуре. Рассмотрим вероятность того, что две разные информационные базы в консоли сервера 1С ошибочно указывают на одну и ту же базу данных в MS SQL Server.
Если по какой-то причине (например, при копировании настроек в консоли) обе базы смотрят на один SQL-ресурс, то любые изменения в «чистой» базе будут мгновенно отражаться в «эталонной» и наоборот. Это также объясняет появление данных: вы просто открыли старую базу под новым именем в списке 1С.
Разберем, что необходимо сделать прямо сейчас, чтобы локализовать проблему и исключить «лунатизм» (непроизвольные действия пользователя):
Посмотрим, нет ли в ЖР событий Информационная база.Загрузка из файла или Информационная база.Восстановление. Если вы загружали dt поверх уже существующей структуры, записи ЖР могли перемешаться. Помните, что загрузка cf (конфигурации) не удаляет данные, а загрузка dt полностью замещает и базу, и ее журнал регистрации.
Проанализируем модуль управляемого приложения и модули обычного приложения. Ищем вызовы обработчиков ожидания:
ПодключитьОбработчикОжидания("ИмяПроцедуры", 60);
Если такая процедура существует, изучим ее содержимое. Она может содержать логику проверки «пустоты» базы и автоматического наполнения из известных источников.
Остановите службу сервера 1С и изучите содержимое папки с логами. Если файл 1Cv8.lgd имеет дату изменения гораздо более раннюю, чем дата создания вашей новой базы, значит, вы столкнулись с эффектом «наследования» журнала. В этом случае записям Данные.Добавление верить нельзя — они могут принадлежать старым сессиям других пользователей.
Часто программисты забывают о расширениях. Проверьте, нет ли в базе подключенных расширений, которые могут перехватывать событие ПриУстановкеНовогоНомера или ПередЗаписью и подтягивать данные через COM из соседних баз. Это популярный способ «автозаполнения» в крупных холдингах.
Появление данных в «чистой» базе — это не магия, а следствие работы алгоритмов. Наиболее вероятный сценарий для платформы 8.3.12: совпадение идентификаторов баз привело к отображению старых логов в новом журнале регистрации, а сами данные попали в базу через механизм инициализации отраслевого решения, который сработал при первом запуске под вашей учетной записью. Для предотвращения подобных ситуаций всегда очищайте кэш сервера и проверяйте настройки SQL-соединений при создании новых узлов системы.