Как перевести базу 1С из SQL в файловый формат

Перевод информационной базы 1С из клиент-серверного варианта (MS SQL Server, PostgreSQL, Oracle) в файловый — стандартная задача администратора. Она возникает при переезде на другой компьютер, создании копии для тестирования, передаче базы франчайзи или отказе от SQL-сервера в небольшой организации. Платформа 1С не умеет «конвертировать» базу напрямую: перенос всегда выполняется через выгрузку данных в файл с расширением .dt и последующую загрузку в новую пустую файловую базу.

Важно понимать суть операции: файл .dt — это полный слепок информационной базы, включая конфигурацию, данные, пользователей и настройки. Именно поэтому способ через выгрузку/загрузку считается единственным штатным и поддерживаемым вендором методом миграции между SQL и файловым режимом. Попытки скопировать файлы SQL-базы (mdf/ldf) и «подсунуть» их файловому варианту не работают — форматы хранения принципиально различны.

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

Когда перевод из SQL в файловый режим оправдан, а когда нет

Прежде чем приступать, оцените, действительно ли файловый вариант подходит вашей задаче. Файловая база хранится в одном файле 1Cv8.1CD и обслуживается платформой напрямую, без СУБД. Это упрощает администрирование, но накладывает серьёзные ограничения на масштаб.

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

Сравнение вариантов размещения

Файловая база

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

SQL-база

Подходит для десятков пользователей и больших объёмов, поддерживает регламентные задания на сервере. Требует администрирования СУБД и лицензий.

Файловая копия для тестов

Типовой сценарий: рабочая база остаётся на SQL, а файловая копия используется для обкатки обновлений и доработок.

Подготовка: что проверить перед выгрузкой

Для выгрузки в .dt потребуется доступ к Конфигуратору с правами администратора информационной базы. Если в базе заведены пользователи с ограниченными правами, убедитесь, что у вашей учётной записи есть роль «Администратор» и право на выгрузку информационной базы. Также проверьте, что вы знаете пароль — без него Конфигуратор просто не откроется.

Оцените размер базы в SQL и свободное место на диске, куда будет сохраняться .dt. Файл выгрузки обычно заметно меньше размера SQL-базы благодаря сжатию, но для крупных баз он всё равно может занимать десятки гигабайт. Запас свободного места должен быть минимум в полтора раза больше предполагаемого размера выгрузки.

Хотя выгрузка не блокирует базу, лучше выбрать время минимальной активности пользователей. Данные, изменённые после начала выгрузки, могут попасть в файл частично, и копия окажется не вполне консистентной с точки зрения бизнес-логики: например, документ проведён, а связанные движения записаны уже после снятия копии.

Шаг 1. Выгрузка базы из SQL в файл .dt

Откройте Конфигуратор нужной базы: в списке информационных баз выберите SQL-базу и нажмите «Конфигуратор». После ввода логина и пароля администратора перейдите в меню «Администрирование» и выберите пункт «Выгрузить информационную базу…». Укажите путь и имя файла с расширением .dt, например trade_copy.dt.

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

1. 1
   Откройте Конфигуратор SQL-базы под учётной записью администратора
2. 2
   Меню «Администрирование» → «Выгрузить информационную базу…»
3. 3
   Укажите путь и имя файла .dt на диске с достаточным свободным местом
4. 4
   Дождитесь завершения выгрузки, не закрывая Конфигуратор
5. 5
   Проверьте, что файл .dt создан и имеет ненулевой размер

Шаг 2. Создание пустой файловой базы и загрузка .dt

Запустите стартовое окно 1С (ярлык «1С:Предприятие») и нажмите «Добавить» → «Создание новой информационной базы». В мастере выберите вариант «Создание информационной базы без конфигурации» — именно пустая база нужна для загрузки .dt. Укажите каталог на локальном диске или сетевом ресурсе, где будет размещаться файл 1Cv8.1CD.

Откройте созданную пустую базу в Конфигураторе. Платформа может предложить создать пользователя-администратора — этот шаг можно пропустить, так как при загрузке .dt список пользователей будет полностью заменён данными из выгрузки. Перейдите в «Администрирование» → «Загрузить информационную базу…» и выберите ранее созданный файл .dt.

После загрузки платформа спросит, перезапустить ли Конфигуратор — согласитесь. База откроется уже с конфигурацией, данными и пользователями из SQL-версии. Войдите под своей прежней учётной записью: логины и пароли переносятся вместе с базой.

Шаг 3. Проверка результата после переноса

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

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

Дополнительно имеет смысл запустить «Тестирование и исправление» информационной базы (Конфигуратор → Администрирование) в режиме проверки без исправления, чтобы убедиться в отсутствии физических ошибок файла после переноса.

Контрольные точки

Как проверить результат

Остатки и обороты за последний период

Норма

Итоги ОСВ и складских отчётов совпадают с SQL-базой

Тревожный признак

Расхождения в суммах или количестве — выгрузка делалась при активных пользователях

Список пользователей и вход

Норма

Все учётные записи на месте, вход под своим паролем работает

Тревожный признак

Пользователей нет или пароль не подходит — загрузка прервалась

Открытие документов и отчётов

Норма

Журналы, документы и печатные формы открываются без ошибок

Тревожный признак

Ошибки формата или «объект не найден» — нужно тестирование и исправление

Типичные ошибки и ограничения

Самая частая ошибка — попытка перенести базу копированием файлов SQL. Файловый и клиент-серверный форматы несовместимы, и никакие манипуляции с mdf-файлами не дадут рабочую файловую базу. Вторая распространённая проблема — загрузка .dt в непустую базу с потерей данных, о чём уже сказано выше.

Ещё одна группа проблем связана с версией платформы. Загрузка .dt возможна только в базу на платформе той же версии или новее, чем та, на которой выполнялась выгрузка. Обратный перенос (с новой платформы на старую) штатно не поддерживается. Также учтите: при загрузке .dt в файловую базу, размещённую на сетевом диске, скорость операции сильно зависит от сети — для больших баз лучше загружать локально, а затем переносить файл 1Cv8.1CD на сетевой ресурс.

Альтернативные сценарии и частные случаи

Перенос только конфигурации без данных

Если нужна пустая файловая база с той же конфигурацией, но без данных, выгружать .dt не обязательно. Достаточно в Конфигураторе SQL-базы сохранить конфигурацию в файл .cf (Конфигурация → Сохранить конфигурацию в файл) и загрузить его в новую пустую файловую базу. Такой вариант быстрее и занимает минимум места.

Очень большая база

Для баз объёмом в сотни гигабайт выгрузка .dt может занять много часов. В этом случае для создания тестовой копии рассмотрите альтернативу: поднять копию на том же SQL-сервере через резервную копию СУБД, а в файловый формат переводить только усечённую копию. Также убедитесь, что на диске нет ограничений файловой системы: на FAT32 файл .dt больше 4 ГБ создать нельзя, используйте NTFS.

Обратный перенос: из файловой в SQL

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

Перед загрузкой .dt сделайте копию самого файла выгрузки на другой диск или сетевой ресурс. Если во время загрузки что-то пойдёт не так (обрыв питания, перезагрузка), не придётся заново ждать многочасовую выгрузку из SQL.

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

Можно ли перевести базу из SQL в файловую без Конфигуратора?

Нет, штатный механизм — только выгрузка/загрузка .dt через Конфигуратор. Существуют пакетные режимы запуска конфигуратора с параметрами командной строки (DumpIB/RestoreIB), но это тот же Конфигуратор, просто без интерактивного интерфейса.

Сколько времени занимает перенос?

Зависит от объёма базы и производительности оборудования. Небольшая база переносится за 10–30 минут, база в десятки гигабайт — за несколько часов. Загрузка .dt обычно идёт дольше выгрузки.

Перенесутся ли пароли пользователей?

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

Что делать, если выгрузка .dt зависает или падает с ошибкой?

Проверьте свободное место на диске, стабильность соединения с SQL-сервером и журналы СУБД на предмет ошибок. Часто помогает перенос выгрузки на локальный диск компьютера с Конфигуратором и выполнение операции в нерабочее время, когда нагрузка на сервер минимальна.

Нужно ли удалять SQL-базу после переноса?

Не сразу. Сохраните SQL-базу в режиме «только чтение» минимум до конца текущего отчётного периода: она понадобится для сверки и как резервная копия, если в файловой версии обнаружатся проблемы. Удалять её стоит только после полной проверки новой базы и создания её резервных копий.

Можно ли работать в файловой базе по сети нескольким пользователям?

Да, файл 1Cv8.1CD можно разместить на общем сетевом ресурсе, и пользователи подключатся через общий доступ либо через веб-сервер. Но при числе одновременных пользователей больше 5–10 производительность и надёжность заметно снижаются — в этом случае лучше оставаться на SQL.