Как исправить ошибку «Файл не обнаружен .tmp» при сохранении или сравнении поврежденной конфигурации 1С?

После аварийного завершения работы сервера, сбоев дисковой подсистемы или некорректного обновления разработчики нередко сталкиваются с ситуацией, когда конфигурация 1С повреждается на уровне отдельных объектов метаданных. При попытке открыть поврежденный модуль, сохранить изменения или выполнить сравнение и объединение конфигураций система падает с критической ошибкой вида «Файл не обнаружен 'C:\Users\...\AppData\Local\Temp\....tmp'».

При этом стандартные средства администрирования — тестирование и исправление, очистка локального кэша, выгрузка и загрузка файла .dt или проверка физической целостности базы данных в СУБД — не приносят результата. Разберем причины возникновения этой проблемы на низком уровне и подробно рассмотрим эффективные сценарии восстановления работоспособности конфигурации.

Выясним причину такого поведения платформы. Внутренняя структура конфигурации хранится в системных таблицах СУБД: Config (основная конфигурация), ConfigSave (редактируемая конфигурация с несохраненными изменениями) и PARAMS. Каждая часть метаданных (структура объектов, модули, формы, макеты) упакована алгоритмом Deflate в виде бинарных блоков (BLOB). Когда происходит сбой, данные внутри бинарного поля повреждаются или обнуляются. Платформа 1С пытается прочитать поток, распаковать его во временный файл операционной системы, но из-за повреждения архива или нулевого размера декомпрессия завершается сбоем, временный файл не формируется, и конфигуратор выдает ошибку отсутствия файла .tmp.

Вариант 1. Сброс несохраненных изменений через СУБД или командную строку

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

Разберем по шагам, как очистить поврежденные временные данные:

1. Обязательно создаем полную резервную копию базы данных средствами СУБД (SQL Server, PostgreSQL и т. д.).
2. Завершаем все сеансы пользователей и закрываем конфигуратор.
3. Если используется клиент-серверный вариант, открываем консоль управления СУБД и выполняем команду очистки таблицы несохраненных изменений:

-- Для Microsoft SQL Server:
DELETE FROM ConfigSave;

Если доступ к СУБД ограничен или требуется выполнить откат средствами платформы, воспользуемся пакетным запуском конфигуратора с ключом возврата к конфигурации базы данных:

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "ServerName\BaseName" /RollbackCfg /N "Admin" /P "Password"

Параметр /RollbackCfg принудительно возвращает конфигурацию к последнему сохраненному состоянию конфигурации базы данных, очищая временные некорректные потоки.

Вариант 2. Локализация битого объекта и замена блока на уровне СУБД

Если повреждение находится в основной конфигурации (в таблице Config), платформа будет завершать работу аварийно при каждом обращении к проблемному объекту. Чтобы заменить поврежденную запись, необходимо точно определить ее идентификатор (GUID).

Рассмотрим, как локализовать и устранить сбой на уровне SQL:

1. Настраиваем сбор событий Технологического журнала 1С, включив отслеживание исключительных ситуаций EXCP и обращений к базе данных DBMSSQL / DBPOSTGRES.
2. Воспроизводим падение конфигуратора (например, открываем поврежденный документ). В логе технологического журнала находим последний запрос SELECT к таблице Config непосредственно перед ошибкой и фиксируем имя поля FileName.
3. Разворачиваем архивную копию базы данных или чистую конфигурацию поставщика в отдельную базу СУБД.
4. Выполняем точечное обновление битого бинарного блока в рабочей базе, взяв корректные данные из резервной копии:

UPDATE TargetDB.dbo.Config
SET TargetDB.dbo.Config.BinaryData = SourceDB.dbo.Config.BinaryData
FROM TargetDB.dbo.Config
INNER JOIN SourceDB.dbo.Config 
    ON TargetDB.dbo.Config.FileName = SourceDB.dbo.Config.FileName
WHERE TargetDB.dbo.Config.FileName = 'ИДЕНТИФИКАТОР_ПОВРЕЖДЕННОГО_ОБЪЕКТА';

Вариант 3. Выгрузка в файлы и ручная замена поврежденных XML-описаний

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

1. Переходим в меню: Конфигурация → Выгрузить конфигурацию в файлы... и указываем целевой каталог.
2. Выполняем аналогичную выгрузку из рабочей резервной копии или эталонного файла поставщика .cf в отдельную папку.
3. Находим каталог поврежденного объекта (например, документа ИнвентаризацияТоваров) и копируем соответствующий файл модуля или структуры из эталонной выгрузки с заменой.
4. Загружаем исправленный комплект обратно в базу через меню: Конфигурация → Загрузить конфигурацию из файлов....

Вариант 4. Пакетная перезагрузка конфигурации из исправленного CF

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

1. В рабочей копии без повреждений (или в чистой базе поставщика с перенесенными доработками) формируем готовый файл configuration.cf.
2. Выполняем пакетную загрузку конфигурации через командную строку:

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "ServerName\BaseName" /LoadCfg "C:\Releases\configuration.cf" /UpdateDBCfg /N "Admin" /P "Password"

Параметр /LoadCfg полностью перезаписывает структуру метаданных, заменяя все поврежденные бинарные потоки в таблице Config без выполнения предварительного сравнения модулей.

Вариант 5. Ручной перенос доработок в чистую конфигурацию поставщика

Если повреждены несколько взаимосвязанных потоков метаданных и конфигурация не поддается автоматическому разбору, наиболее надежным решением является сборка новой рабочей конфигурации:

1. Берем типовую конфигурацию поставщика нужного релиза.
2. Используя последний неповрежденный бэкап и текст доработок, переносим пользовательский функционал в чистый файл .cf.
3. Загружаем итоговый файл .cf в рабочую базу целиком через режим Конфигурация → Загрузить конфигурацию из файла... (без использования режима сравнения и объединения).
4. Обновляем конфигурацию базы данных клавишей F7.

Важно: чтобы избежать подобных ситуаций в будущем, настройте автоматическое регулярное резервное копирование как на уровне СУБД (дампы транзакций и полные бэкапы), так и на уровне ежедневной выгрузки конфигурации в файл .cf перед внесением любых изменений.