Что делать, если файл CONST.DBF в 1С 7.7 стал слишком большим и база начала выдавать ошибки

Программист 1С v7.7 IT и автоматизация бизнеса
← На главную

Проблема разрастания файла CONST.DBF является критической для пользователей и разработчиков систем на базе «1С:Предприятие 7.7». Когда размер этого файла приближается к отметке в 2 Гигабайта, база данных начинает вести себя нестабильно, выдавать ошибки при записи или вовсе «сыпаться». Это связано с фундаментальными ограничениями формата DBF, который не поддерживает файлы объемом более 2 Гб.

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

Выясняем причины разрастания файла CONST.DBF

Для начала проанализируем, за что отвечает файл CONST.DBF. В отличие от таблиц справочников или документов, этот файл хранит:

  1. Значения всех констант (если они не периодические, то по одной записи на константу).
  2. Историю изменений периодических констант.
  3. Историю всех периодических реквизитов справочников.

Чаще всего виновниками гигантского размера файла становятся именно периодические реквизиты (например, цены товаров, курсы валют или сведения о сотрудниках). Если в базу регулярно загружаются данные из внешних систем (например, прайс-листы поставщиков), система может записывать значение реквизита на каждый день, даже если сама цена не менялась. Рассмотрим ситуацию: 01.01.2023 цена была 100 рублей, и 02.01.2023 она осталась 100 рублей. Если программно записать значение на 02.01.2023, в CONST.DBF появится новая строка, хотя фактически информация не обновилась.

Шаг 1: Глубокая диагностика содержимого

Прежде чем что-то удалять, нам необходимо понять, какие именно данные занимают место. Использовать стандартные средства 1С для этого неудобно, поэтому воспользуемся внешними инструментами. Рассмотрим применение консоли запросов 1sqlite, которая позволяет выполнять SQL-запросы к DBF-файлам.

Выполним следующий запрос, чтобы увидеть статистику по типам данных в таблице:


SELECT
    ID [ВидКонстанты $ИмяВида],
    count(*) [Количество]
FROM __1S_CONST
GROUP BY ID
ORDER BY count(*) DESC

Этот запрос покажет нам «топ-10» реквизитов, которые создают наибольшее количество записей. Если мы видим, что какой-то один реквизит (например, ЦенаЗакупки) имеет миллионы записей, значит, проблема именно в нем.

Шаг 2: Очистка лишних периодических значений

Если мы обнаружили избыточность, ситуацию нужно исправлять. Разберем основные методы очистки:

  1. Удаление старых значений: Часто история цен за 10 лет не имеет практической ценности. Можно программно удалить записи периодических реквизитов до определенной даты.
  2. Удаление дублирующихся записей: Нам нужно избавиться от записей, которые не несут новой информации. Если значение на текущую дату совпадает со значением на предыдущую дату, запись в CONST.DBF является лишней.

Для массовой очистки периодических реквизитов рекомендуется использовать специализированные обработки (например, с портала Инфостарт или Миста). Если вы решили написать свою обработку, используйте объект Периодический.

Шаг 3: Оптимизация программного кода (Профилактика)

Чтобы файл не вырос снова через месяц, проанализируем код, отвечающий за запись данных. Рассмотрим типичную ошибку и правильный вариант реализации.

Плохо: Просто записывать значение каждый раз при загрузке.


Спр = СоздатьОбъект("Справочник.Номенклатура");
// ... поиск элемента ...
Спр.Цена.Установить(РабочаяДата(), НоваяЦена);
Спр.Записать();

Хорошо: Сначала проверим, отличается ли новое значение от уже установленного.


Спр = СоздатьОбъект("Справочник.Номенклатура");
// ... поиск элемента ...
ТекЦена = Спр.Цена.Получить(РабочаяДата());
Если ТекЦена <> НоваяЦена Тогда
    Спр.Цена.Установить(РабочаяДата(), НоваяЦена);
    Спр.Записать();
КонецЕсли;

Этот простой блок Если ... КонецЕсли способен сократить рост файла CONST.DBF в десятки раз, особенно при ежедневных обменах данными.

Шаг 4: Выгрузка и загрузка данных

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

Рассмотрим самый эффективный способ «сжатия» базы:

  1. Зайдите в Конфигуратор.
  2. Выберите пункт меню «Администрирование» -> «Выгрузка данных». Создайте файл .zip.
  3. Создайте пустую папку для новой базы.
  4. В новой папке через Конфигуратор выполните «Администрирование» -> «Загрузка данных».

Проанализируем результат: при этой процедуре 1С пересоздает структуру таблиц и записывает только актуальные данные. В описанном на форуме случае размер файла CONST.DBF уменьшился с 2 Гб до 300 Мб. Важно: Перед выполнением этих действий обязательно сделайте архивную копию базы!

Шаг 5: Работа с «осиротевшими» записями

Иногда документы или элементы справочников удаляются, а записи об их периодических реквизитах в CONST.DBF остаются. Процедура «Тестирование и исправление» (ТиИ) с включенными галочками «Проверка ссылочной целостности» и «Очистка ссылок» помогает избавиться от таких записей. Однако на больших объемах ТиИ может работать крайне долго или падать с ошибкой. В таких случаях выгрузка/загрузка данных, описанная в Шаге 4, является более предпочтительной, так как она игнорирует объекты, не имеющие владельцев в метаданных.

Альтернативные архитектурные решения

Если специфика вашего бизнеса требует хранения огромного количества изменений (например, котировки акций каждые 5 минут), механизм периодических реквизитов 1С 7.7 вам не подходит. В этом случае рассмотрим другие варианты:

Подводя итог, отметим, что «смерть» базы 1С 7.7 из-за файла CONST.DBF — это лишь следствие неоптимальной записи данных. Регулярный мониторинг размера таблиц, использование проверки значений перед записью и периодическая пересборка базы (выгрузка/загрузка) позволят вашей системе работать стабильно долгие годы.

← На главную