При работе с историческими базами 1С:Предприятие 7.7 системные администраторы и программисты часто сталкиваются с аппаратным ограничением файловой системы или движка базы данных: файл не может превышать размер 2 Гб. В бухгалтерских базах наиболее уязвимым местом является таблица 1SBKTTL.DBF, в которой хранятся итоги. Если этот файл приблизился к отметке 1.9 Гб, любая попытка свертки стандартной обработкой wrap.ert приводит к аварийному завершению программы, так как в процессе пересчета итогов размер файла неизбежно перешагивает критический порог.
Рассмотрим комплексный подход к решению этой задачи, разберем по шагам несколько методик — от простых манипуляций с периодами до технологического перехода на SQL.
Основная ошибка при свертке большой базы — попытка обработать весь период (например, за 5 лет) за один раз. В этом случае объем временных данных и логов транзакций переполняет таблицу. Проанализируем, как сделать это безопаснее:
wrap.ert минимально возможный интервал.PACK в терминах DBF). В конфигураторе это делается через меню "Администрирование" — "Тестирование и исправление ИБ" с выбранным пунктом "Упаковка таблиц".1SBKTTL.DBF в папке базы данных. Если после очередной итерации и упаковки размер уменьшился, продолжаем процесс.Файл 1SBKTTL.DBF растет пропорционально количеству периодов (месяцев), за которые рассчитаны итоги. Если мы сдвинем границу рассчитанных итогов в прошлое, система физически удалит записи из этой таблицы. Разберем этот алгоритм:
Заходим в режим "1С:Предприятие" — "Операции" — "Управление бухгалтерскими итогами". Посмотрим, на какой квартал установлена дата расчета. Если база ведется долго, там может стоять текущий год. Установим расчет итогов на дату, предшествующую началу свертки на 1-2 года. Система предложит пересчитать итоги — соглашаемся. После этого размер файла 1SBKTTL.DBF существенно уменьшится, освободив «запас» для работы обработки свертки.
Стандартная обработка wrap.ert работает не самым оптимальным образом: она одновременно создает документы остатков и пытается удалять старые проводки, что вызывает лавинообразный пересчет итогов. Выясним причину торможения и устраним ее, модифицировав код или логику процесса.
Разделим процесс на два этапа:
Примерно так может выглядеть фрагмент кода для массового снятия проведения без лишних затрат ресурсов:
Док = СоздатьОбъект("Документ");
Док.ВыбратьДокументы(ДатаНач, ДатаКон);
Пока Док.ПолучитьДокумент() = 1 Цикл
Если Док.Проведен() = 1 Тогда
Док.СделатьНепроведенным();
// Здесь можно добавить счетчик для визуального контроля
КонецЕсли;
КонецЦикла;
После массового снятия проведения со всех документов за старые периоды, запускаем "Тестирование и исправление" один раз в самом конце. Это в десятки раз быстрее, чем пересчет после каждого документа.
Если размер базы критический, а рисковать данными нельзя, проанализируем вариант с использованием SQL. Ограничение в 2 Гб — это особенность формата DBF. В Microsoft SQL Server таких ограничений нет (даже в бесплатной версии Express лимит базы составляет 10 Гб).
Алгоритм действий следующий:
На выходе мы получим чистую DBF-базу, размер которой будет далеко от критического порога.
Существуют неофициальные патчи для системной библиотеки dbeng32.dll (например, версии от Ромикса или Вирта), которые позволяют 1С 7.7 работать с DBF-файлами размером до 4 Гб. Рассмотрим этот метод как экстренный:
Заменяем оригинальный файл dbeng32.dll в каталоге установленной программы 1С на модифицированный. Это позволит базе "проглотить" файл размером более 2 Гб во время свертки. Однако будьте осторожны: после завершения свертки настоятельно рекомендуется вернуть базу в стандартный вид (до 2 Гб) и использовать оригинальные библиотеки, так как работа на патченных компонентах может снизить стабильность системы и усложнить поддержку.
Иногда проще не резать старое, а перенести нужное в новое. Если база сильно раздута, проанализируем ситуацию: возможно, в ней накопилось много «мусора» в виде незакрытых копеечных остатков по субконто, которые и раздувают 1SBKTTL.DBF.
Пошаговый план:
Universal.ert или выгрузки/загрузки XML).Этот метод является самым «чистым» с точки зрения качества данных, так как в новую базу не перекочуют ошибки прошлых периодов и битые индексы.
Подводя итог, отметим, что наиболее стабильным и безопасным методом для программиста является Метод 4 (SQL-транзит) или Метод 2 (Сдвиг итогов). Если же вы решили идти по пути удаления документов в DBF, всегда делайте копию перед каждым этапом. Помните, что 1SBKTTL.DBF — это производная таблица, ее всегда можно пересчитать из таблицы операций 1SENTRY.DBF, но именно она блокирует работу системы при достижении лимита. После успешной свертки обязательно проверьте корректность остатков на счетах 00 или других вспомогательных счетах, используемых при переносе.