Работа с платформой 1С:Предприятие 7.7 в формате DBF накладывает определенные ограничения, особенно когда речь идет о «тяжелых» справочниках (например, «Номенклатура» с количеством записей от 50 000 до нескольких миллионов). Стандартная процедура добавления даже самого простого реквизита (типа «флажок» или «число») через Конфигуратор может растянуться на многие часы. Это происходит из-за того, что система выполняет полную реструктуризацию таблицы, создавая временные файлы в папке NEW_STRU и последовательно переписывая каждую запись, одновременно обновляя индексы.
В этой статье мы разберем, почему это происходит, и рассмотрим эффективные методы ускорения процесса — от штатных манипуляций с настройками до «хирургического» вмешательства в структуру таблиц.
Разберем причину замедления. При реструктуризации платформа 1С 7.7 выполняет следующие действия:
NEW_STRU..dbf в новый..cdx практически в реальном времени при добавлении записей.На обычных жестких дисках (HDD) это вызывает лавинообразный рост нагрузки на дисковую подсистему из-за постоянного перемещения головок между данными и индексами. Ситуация усугубляется, если размер ключа индекса близок к пределу или база работает в многопользовательском режиме по сети.
Прежде чем переходить к внешним утилитам, попробуем ускорить процесс встроенными средствами. Основной тормоз реструктуризации — индексы. Мы можем временно «облегчить» таблицу.
Рассмотрим алгоритм действий:
НеВключатьВпрайс в типовых решениях ТиС.Этот метод позволяет сократить время работы в разы, так как перестроение индексов с нуля после изменения структуры файла часто происходит быстрее, чем их обновление «на лету» в процессе копирования данных.
Если справочник настолько велик, что даже снятие галочек не помогает, воспользуемся методом прямой подмены данных. Основная проблема ручного редактирования .dbf файлов — риск повредить заголовок таблицы (длину записи или смещение данных), что приведет к ошибкам при Тестировании и исправлении (ТиИ).
Разберем самый безопасный путь с использованием редактора (например, Sdbf):
.dbf справочника в другую папку, чтобы 1С создала новый пустой файл с правильным заголовком).SC123.dbf), соответствующий новой структуре в 1cv7.md и 1cv7.dd.*.cdx и запускаем 1С для переиндексации.Этот метод гарантирует, что заголовок таблицы будет идеально соответствовать требованиям 1С, так как его создала сама платформа, а мы лишь наполнили таблицу данными.
Если вы не хотите использовать стороннее ПО, мы можем написать простую обработку в самой 1С, которая перенесет данные программно. Это безопаснее, чем внешние редакторы.
Проанализируем пример кода для такой операции:
// Пример логики переноса данных через XBase
Процедура ВыполнитьПеренос()
СтараяТаблица = СоздатьОбъект("XBase");
НоваяТаблица = СоздатьОбъект("XBase");
// Путь к архивному (старому) файлу
СтараяТаблица.ОткрытьФайл("C:\Temp\SC123_old.dbf");
// Путь к новому пустому файлу (созданному Конфигуратором)
НоваяТаблица.ОткрытьФайл(КаталогИБ() + "SC123.dbf");
СтараяТаблица.ВыбратьЗаписи();
Пока СтараяТаблица.Следующая() = 1 Цикл
НоваяТаблица.Добавить();
// Переносим все существующие поля программно
Для НомерПоля = 1 По СтараяТаблица.КоличествоПолей() Цикл
ИмяПоля = СтараяТаблица.ПолучитьИмяПоля(НомерПоля);
НоваяТаблица.УстановитьЗначение(ИмяПоля, СтараяТаблица.ПолучитьЗначение(ИмяПоля));
КонецЦикла;
// Новое поле заполнится значением по умолчанию автоматически
НоваяТаблица.Записать();
КонецЦикла;
СтараяТаблица.ЗакрытьФайл();
НоваяТаблица.ЗакрытьФайл();
Предупреждение("Перенос завершен!");
КонецПроцедуры
Использование XBase позволяет избежать проблем с форматами dBase IV, так как 1С работает со своими файлами максимально корректно.
Ограничение 117 байт: В 1С 7.7 DBF существует критический порог длины ключа индекса. Если вы добавляете реквизит и включаете по нему сортировку, а суммарная длина индексируемых полей (например, при иерархическом списке это ID родителя + Наименование + ваш реквизит) превышает 117 байт, производительность падает в десятки раз. Выясним, нет ли у вас избыточных индексов перед началом работ.
Тип реквизита: Для простого «флажка» часто используют Число длиной 1. Однако в DBF это может занимать больше места из-за специфики хранения. Если база критически огромная, иногда рассматривают вариант использования типа Строка длиной 1 (со значениями "0" и "1"), что работает чуть быстрее при массовых операциях.
Антивирусы и кэширование: При выполнении реструктуризации обязательно отключайте антивирусное сканирование каталога базы данных. Антивирус блокирует файл NEW_STRU при каждой записи, что превращает минуты в часы.
Таким образом, комбинируя временное отключение индексов и использование прямого импорта данных в чистую структуру, мы можем сократить время обслуживания базы с целого рабочего дня до 15-20 минут.