Работа с базами данных 1С:Предприятие 7.7 в формате DBF накладывает жесткое техническое ограничение: размер любого отдельного файла таблицы (например, 1SENTRY.DBF или 1SJOURN.DBF) не может превышать 2 Гб. При достижении этого порога база начинает работать нестабильно, возникают ошибки записи, а стандартные механизмы удаления данных становятся крайне медленными. Рассмотрим комплексный подход к «обрезке» базы, позволяющий существенно уменьшить её размер и восстановить корректность итогов.
Прежде чем приступать к удалению данных, проанализируем, почему штатные средства 1С работают медленно. Основная причина — постоянный пересчет итогов и индексов при удалении каждого документа. Если мы пытаемся удалить документы за 10–15 лет, система тратит колоссальное время на поддержание актуальности регистров и бухгалтерских итогов (БИ). Выясним основные причины «тормозов»:
.cdx.Рассмотрим алгоритм подготовки, который позволит ускорить процесс в десятки раз.
Для ускорения процесса удаления документов воспользуемся тактикой временного отключения механизмов расчета. Разберем по шагам наиболее эффективный сценарий:
Шаг 1. Формирование остатков. Сначала создадим документы ввода остатков на дату свертки (например, на 01.01.2023). Эти документы должны быть заполнены, но не проведены.
Шаг 2. Откат точки актуальности. Установим ТА и период расчета бухгалтерских итогов на дату начала самых старых документов в базе. Это минимизирует объем вычислений при распроведении и удалении.
Шаг 3. Распроведение документов. Массово распроведем все документы до даты свертки. Без проведения документы превращаются в обычные записи в таблицах, не влияющие на регистры.
Шаг 4. Очистка табличных частей. Перед удалением самих документов полезно программно очистить их табличные части. Это значительно уменьшит объем файлов DT* (для документов) и 1SENTRY (для проводок), что облегчит последующую «упаковку» таблиц.
Шаг 5. Пометка на удаление и удаление. Выполним пометку на удаление порциями (например, по 1 году). После пометки запустим процедуру удаления помеченных объектов. Если база очень большая, лучше делать это в монопольном режиме.
Если штатное удаление даже после оптимизации занимает слишком много времени, проанализируем возможность использования прямого доступа к данным. Этот метод считается «агрессивным», но он самый быстрый. Для его реализации используется провайдер VFPOLEDB.
Посмотрим на пример строки соединения, которую можно использовать в обработке:
Соединение = "Provider=VFPOLEDB.1;Data Source=" + КаталогИБ() + ";Exclusive=Yes;Mode=ReadWrite;Collating Sequence=MACHINE";
При использовании этого метода мы можем напрямую удалять записи из таблиц 1SJOURN, 1SENTRY, RA* (движения регистров). Важно: записи в DBF при удалении помечаются специальным флагом, но физически остаются в файле. Чтобы файл реально уменьшился в размере, после завершения операций необходимо выполнить Упаковку таблиц в Конфигураторе.
Однако помните: прямое удаление из таблиц движений «ломает» итоги в таблицах RG* и 1SBKTTL, так как они не обновляются автоматически. Поэтому после такого удаления обязательно требуется полное восстановление итогов.
Часто после свертки пользователи замечают, что остатки в отчетах стали нулевыми или, наоборот, увеличились вдвое. Это происходит из-за рассинхронизации таблиц движений и таблиц остатков. Разберем способ радикального исправления этой ситуации:
.cdx из каталога базы данных.1SBKTTL.DBF и 1SBKTTLC.DBF. Это заставит систему при следующем запуске пересчитать всё с чистого листа на основе только оставшихся проводок в 1SENTRY.Рассмотрим ситуацию, когда база настолько велика, что ни один из методов в формате DBF не позволяет завершить процесс за приемлемое время. В этом случае эффективным решением будет временная миграция на MS SQL Server (даже версии Express):
TRUNCATE или DELETE происходит мгновенно.В процессе свертки часто выясняется, что «глючат» не сами данные, а отчеты. Проанализируем пример, когда стандартная Оборотно-сальдовая ведомость внезапно перестает показывать данные. Выясним причину на примере фрагмента кода:
Иногда программисты используют специфическое форматирование вывода чисел, которое зависит от глобальных переменных. Если в коде отчета отсутствует инициализация строки формата, данные могут визуально пропадать:
// В некоторых конфигурациях формат суммы определяется динамически
сФорматС = "Ч0" + (Метаданные.ДлинаСуммыПроводки) + "." + Метаданные.ТочностьСуммыПроводки;
// Если эта строка не отработала, функция ФорматС() вернет пустую строку
ДанныеДляВывода = ФорматС(Ит.СНД(), сФорматС);
Проверьте, чтобы в ваших внешних отчетах, которыми вы сверяете базу «До» и «После», формат вывода был жестко задан или корректно инициализировался. Это исключит ситуацию «мнимого» отсутствия итогов.
*.cdx) и файлы бухгалтерских итогов (1SBKTTL*).VFPOLEDB для скорости).Соблюдение этой последовательности позволит вам избежать многосуточного ожидания и получить чистую, компактную базу с корректными остатками.