Как конвертировать базу данных 1С

Конвертация базы данных 1С требуется в нескольких ситуациях: при обновлении платформы, когда старый формат файла данных не открывается новой версией, при переходе с файлового режима на клиент-серверный, при переносе данных между конфигурациями и при миграции на другое оборудование. В каждом случае действует свой механизм, и смешение этих сценариев — главная причина поврежденных баз и потерянных данных.

Важно различать два смысла слова «конвертация». Первый — технический: изменение формата файла 1Cv8.1CD или перенос базы на СУБД, при этом структура конфигурации и данные остаются прежними. Второй — прикладной: перенос данных между разными конфигурациями (например, из «1С:Управление торговлей 10.3» в «Управление торговлей 11») по правилам обмена. Это принципиально разные задачи с разными инструментами и рисками.

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

Определите, какая именно конвертация вам нужна

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

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

Подготовка: резервная копия и проверка исходной базы

Любая конвертация начинается с резервной копии, причём не той, что делалась «когда-то», а свежей и проверенной. Для файловой базы скопируйте файл 1Cv8.1CD при отсутствии активных сеансов или сделайте выгрузку в .dt через конфигуратор (Администрирование → Выгрузить информационную базу). Для клиент-серверной базы используйте средства СУБД — это надёжнее и быстрее выгрузки .dt.

Перед конвертацией выполните тестирование и исправление исходной базы (Администрирование → Тестирование и исправление) с включённой проверкой ссылочной целостности. Ошибки, которые незаметны в повседневной работе, при конвертации могут оборвать процесс или привести к потере объектов. Также завершите все фоновые задания и попросите пользователей выйти: активные сеансы блокируют монопольный режим, необходимый для большинства операций.

Проверьте свободное место на диске: для конвертации файловой базы потребуется объём, сопоставимый с размером исходного файла, а при выгрузке в .dt — дополнительно место под файл выгрузки и временные файлы. Для баз в десятки гигабайт нехватка места на середине процесса — типичная причина обрыва.

Конвертация формата файловой базы под новую платформу

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

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

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"D:\Bases\MyBase" /Convert

Для старых баз формата 8.2, которые нужно перевести в формат 8.3 без запуска конфигуратора, используется утилита cnvdbfl.exe из каталога bin платформы. Она работает из командной строки и подходит для массовой конвертации.

cnvdbfl.exe -c -i "D:\Bases\MyBase\1Cv8.1CD"

После конвертации формата базу нельзя открыть старой версией платформы — обратная совместимость отсутствует. Поэтому конвертируйте только после того, как все рабочие места и сервер обновлены до целевой версии платформы.

Перенос файловой базы на клиент-серверный вариант

Переход на SQL — тоже разновидность конвертации, и выполняется он через выгрузку/загрузку .dt. Порядок такой: выгрузите файловую базу в файл .dt, создайте пустую информационную базу на сервере 1С с указанием СУБД (MS SQL Server или PostgreSQL), откройте её конфигуратором и загрузите .dt (Администрирование → Загрузить информационную базу).

1. 1
   Сделайте резервную копию файловой базы и проверьте её открытие
2. 2
   Выгрузите базу в файл .dt через конфигуратор
3. 3
   Создайте пустую базу на сервере: в консоли кластера добавьте ИБ с указанием СУБД и пустой базы данных
4. 4
   Откройте новую базу конфигуратором и загрузите .dt
5. 5
   Выполните тестирование и исправление, обновите конфигурацию базы данных при необходимости
6. 6
   Проверьте открытие ключевых документов и отчётов, сверьте обороты с исходной базой

Учтите ограничения. Файл .dt — не средство повседневного бэкапа для больших баз: выгрузка и загрузка занимают много времени, а при повреждении отдельных таблиц загрузка может завершиться ошибкой. Для баз объёмом в десятки гигабайт перенос через .dt может занять часы; планируйте операцию на нерабочее время. Также помните, что .dt, созданный на более новой платформе, не загружается на старую.

Перенос данных между конфигурациями через «Конвертацию данных»

Когда меняется сама прикладная конфигурация, простая выгрузка не поможет: структуры объектов различаются. Для этого служит технология «Конвертация данных»: в конфигурации «Конвертация данных» (редакция 2 или 3) описываются правила соответствия объектов источника и приёмника, затем обработка выгрузки формирует XML-файл, который загружается в целевую базу.

Для типовых переходов (например, с «1С:Бухгалтерии 7.7» на «1С:Бухгалтерию 8» или между редакциями УТ) существуют готовые правила и обработки переноса, поставляемые вендором или доступные на портале 1С. Используйте именно их: самостоятельное написание правил с нуля оправдано только для нестандартных или сильно доработанных конфигураций.

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

Проверка результата конвертации

Конвертация считается завершённой не тогда, когда закрылось окно прогресса, а когда подтверждена целостность данных. Минимальный набор проверок одинаков для всех сценариев.

Во-первых, выполните тестирование и исправление уже на целевой базе — это выявит ошибки, возникшие при переносе. Во-вторых, сверьте контрольные итоги: сальдо по оборотно-сальдовой ведомости, остатки по складу и по расчётам с контрагентами в старой и новой базе на одну и ту же дату должны совпадать до копейки. В-третьих, откройте выборочно документы разных видов и убедитесь, что табличные части и движения на месте.

Старую базу не удаляйте: переведите её в архивный режим «только чтение» и храните минимум несколько лет — она понадобится для налоговых проверок и сверок первичных документов.

Границы самостоятельной работы и когда нужен специалист

Техническая конвертация формата и переход файловой базы на SQL при типовой конфигурации и актуальных релизах — задачи, выполнимые системным администратором по инструкции. Риски здесь в основном инфраструктурные: место на диске, монопольный доступ, версии платформы.

К специалисту по внедрению стоит обращаться, если конфигурация сильно доработана (типовые правила переноса не покроют самописные документы и регистры), если база большая и даунтайм критичен (нужна стратегия поэтапного перехода), если источник повреждён или если переход идёт с платформы 7.7 с нестандартными данными. В этих случаях цена ошибки — потеря учётных данных, и экономия на специалисте оборачивается восстановлением базы.

Частые вопросы