Перенос файловой информационной базы 1С в другой каталог или на другой диск — задача, казалось бы, тривиальная. Однако системные администраторы часто сталкиваются с ситуацией, когда после простого копирования файла 1Cv8.1cd и изменения пути в списке баз программа выдает критическую ошибку: «Файл базы поврежден». При этом восстановление той же самой базы из архива в ту же папку решает проблему. Разберем подробно, почему это происходит и как правильно выполнять перенос без лишних манипуляций с бекапами.
Проанализируем состав папки информационной базы. Помимо основного файла данных 1Cv8.1cd, в каталоге часто находятся временные файлы и файлы блокировок:
1Cv8.cfl — файл блокировки базы.1Cv8.1cl или 1Cv8.lgk — файлы, содержащие информацию о текущих сеансах и транзакциях.1Cv8Log — журнал регистрации.1Cv8JobScheduler — данные планировщика заданий.Если копирование производилось в момент, когда база не была полностью «отпущена» операционной системой или антивирусом (даже если пользователи вышли), эти служебные файлы могут зафиксировать некорректное состояние. Платформа 1С при запуске по новому пути видит эти файлы и пытается восстановить сессию, которая «зависла» в другом расположении, что и приводит к ошибке целостности. Решение: при переносе базы вручную копируйте только файл 1Cv8.1cd. Все остальные служебные структуры платформа создаст заново при первом запуске.
Рассмотрим механизм работы списка баз. Каждая запись в файле ibases.v8i содержит не только путь к папке (параметр Connect), но и уникальный идентификатор ID. Платформа 1С привязывает локальный кэш (настройки форм, временные данные метаданных) именно к этому ID и пути.
Если вы просто меняете путь в существующей записи .v8i, 1С может попытаться использовать старый кэш для нового расположения. Если в старом кэше остались следы «динамического обновления» или незавершенных фоновых процессов, возникнет конфликт, который интерпретируется как повреждение файла. Выясним, как этого избежать:
ID и чистую папку кэша.%AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\.Посмотрим на важную техническую деталь: запуск в режиме «1С:Предприятие» и «Конфигуратор» происходит по-разному. Режим предприятия более чувствителен к наличию временных файлов в каталоге базы. Если база была перенесена некорректно, «Предприятие» сразу выдаст ошибку.
Рекомендуемый алгоритм: после переноса файла базы на новое место первый запуск всегда выполняйте через Конфигуратор. Конфигуратор обладает механизмами «мягкого» восстановления заголовка файла базы и инициализации служебных структур. После того как база успешно открылась в Конфигураторе, её можно закрывать и запускать в обычном пользовательском режиме.
Проанализируем ситуацию, связанную с операционной системой. При копировании больших бинарных файлов (каким является 1Cv8.1cd) через проводник Windows на другой диск может произойти микросбой файловой системы или вмешательство антивирусного монитора. Кроме того, на новом диске файл может унаследовать права доступа, запрещающие пользователю запись, что 1С иногда ошибочно трактует как «повреждение».
Для диагностики воспользуемся стандартной утилитой chdbfl.exe, которая находится в папке bin установленной платформы. Рассмотрим пример запуска проверки:
chdbfl.exe.1Cv8.1cd.Если утилита не находит ошибок, значит, проблема стопроцентно кроется в кэше или блокировочных файлах (см. пункты 1 и 2).
Чтобы исключить появление ошибки «Файл базы поврежден» в будущем, рекомендуем следовать проверенной инструкции:
1cv8.exe или 1cv8c.exe..dt) через Конфигуратор. Это самый надежный способ, так как платформа сама упаковывает данные в логически целостный архив..dt, копируйте только один файл 1Cv8.1cd через файловые менеджеры, умеющие проверять контрольные суммы (например, Total Commander или FAR Manager)./ClearCache, однако это лишь временная мера.Подводя итог, можно сказать: ошибка при переносе чаще всего вызвана тем, что вместе с базой переносятся «хвосты» старых сессий или используются устаревшие записи кэша. Соблюдение правила «один файл данных — новый путь в списке — запуск через Конфигуратор» сводит риск порчи базы к минимуму.