Работа в информационных базах на устаревшей платформе «1С:Предприятие 7.7» в файловом режиме (DBF/CDX) рано или поздно сталкивает администраторов и разработчиков с физическими ограничениями СУБД. В типовой конфигурации «Торговля и Склад 9.2» наиболее уязвимым местом является регистр партий (таблицы движений RA328.dbf и итогов RG328.dbf). При достижении размера файла около 1 ГБ стабильность базы данных начинает стремительно падать, а при достижении 2 ГБ система полностью блокирует запись в таблицу.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем симптомы «умирающей» файловой базы и детально изучим пять практических способов решения: от оперативных «костылей» до глубокой модернизации и миграции на современные платформы.
---
Для начала выясним причину, почему файлы DBF начинают сбоить задолго до достижения физического лимита операционной системы. Встроенный движок 1С 7.7 (CodeBase) использует 32-битное знаковое смещение для адресации данных. Это накладывает жесткое ограничение на размер одного файла — 2 147 483 647 байт (2 ГБ).
Однако проблемы (так называемые «глюки») начинаются гораздо раньше — при превышении порога в 1 ГБ. Проанализируем типичные симптомы:
.CDX).Если вы заметили подобные симптомы, а размер файла движений регистра (например, RA328.dbf) или итогов перешагнул отметку в 900–950 МБ, медлить нельзя — капец, как верно заметил автор темы, всегда наступает не вовремя. Рассмотрим все доступные варианты решения.
---
Если у вас нет ресурсов на немедленный переход на SQL или «восьмерку», но базу нужно удержать в работоспособном состоянии еще на год-два, рассмотрим варианты расширения возможностей DBF-формата.
Использование DLL-патчей (Kernel3x)
Существует неофициальная библиотека-перехватчик (известная как патч от hogik или Kernel3x), которая подменяет системные вызовы работы с файлами. Она позволяет платформе 1С 7.7 корректно адресовать DBF-файлы размером до 4 ГБ. Для внедрения этого решения достаточно заменить оригинальные библиотеки в каталоге платформы на модифицированные.
Важное предупреждение: это высокорискованный метод. Любое аварийное завершение работы пользователя (сбой сети, отключение электричества на сервере) в момент записи в файл размером более 2 ГБ с высокой долей вероятности приведет к безвозвратному разрушению базы данных. Регулярный бэкап при таком режиме работы должен выполняться несколько раз в день.
Переход на Advantage Database Server (ADS)
Более надежный профессиональный путь без ухода от DBF — использование клиент-серверной СУБД Advantage Database Server. Специальная ВК подменяет библиотеку BkEnd.dll, заставляя 1С работать с файлами DBF/CDX через серверный процесс ADS. Это полностью решает проблему ограничения размера файлов в 2 ГБ, кардинально снижает сетевой трафик и защищает таблицы от повреждения при обрыве сессий терминальных пользователей.
---
Прежде чем менять СУБД, проанализируем структуру раздувшегося регистра. Возможно, таблица RA328.dbf хранит много избыточной информации, от которой можно отказаться без вреда для учета.
Разберем по шагам, как уменьшить размер регистра за счет оптимизации метаданных:
Фирма или Склад, их можно удалить из структуры регистра в Конфигураторе. Это уменьшит ширину каждой строки таблицы движений на десятки байт, что в масштабе миллионов записей сэкономит сотни мегабайт.ЦенаПрод (цена продления/продажи) часто дублируется или вовсе не используется в алгоритмах списания себестоимости. Также проверьте ресурсы СуммаУправленческая и СуммаРуб — если они всегда равны, от одного из них можно избавиться, скорректировав программный код проведения.Количество на 15.2 или даже 15.0. Это существенно снизит физический объем, занимаемый числами в DBF.Для анализа максимальных значений и точности полей перед изменением структуры мы можем выполнить проверочный SQL-запрос (если база уже перенесена на SQL или тестируется на копии):
SELECT
max(Количество) as [МаксКоличество],
max(СуммаРуб) as [МаксСумма]
FROM
РегистрИтоги_ПартииНаличие
После изменения метаданных в Конфигураторе запустите реструктуризацию таблиц. База данных физически уменьшится в размерах.
---
Перевод базы данных 1С 7.7 на MS SQL Server — это классический и наиболее надежный способ забыть об ограничениях на размер таблиц навсегда. Однако штатный переход сопряжен с рядом трудностей на современных операционных системах.
Разберем основные проблемы совместимости и способы их решения при миграции на MS SQL Server 2016/2019/2022:
Проблема 1. Ошибка ODBC-драйвера
При попытке запустить SQL-версию 1С 7.7 на современных ОС Windows Server выдается ошибка: "Требуется SQL Server 6.5 SP5a или выше".
Для решения этой проблемы примените один из вариантов:
sqlsrv32.dll и sqlsrv32.rll в папке SysWOW64 на аналогичные файлы от Windows Server 2003.BkEnd.dll), снимающие эту проверку на уровне кода платформы.Проблема 2. Кодовая страница и сортировка
Часто возникает ошибка: "Порядок сортировки отличается от системного". Чтобы обойти это ограничение, создайте в каталоге базы данных (или в каталоге BIN платформы) пустой текстовый файл с именем OrdNoChk.prm. Также при создании базы данных на MS SQL Server обязательно задайте кодировку (Collation) как Cyrillic_General_CI_AS.
Проблема 3. Совместимость с MS SQL Server 2022
Начиная с версии MS SQL 2022, Microsoft убрала поддержку старого синтаксиса указания индексов в запросах (конструкции вида FROM TABLE (NOLOCK INDEX=...)). Штатный движок 1С 7.7 генерирует именно такие запросы, что приводит к полному краху СУБД при попытке провести любой документ.
Для обхода этой проблемы рекомендуется использовать MS SQL Server 2019 (с установкой уровня совместимости Compatibility Level 150) или применять современные сборки платформы, которые на лету перехватывают и корректируют SQL-запросы платформы под требования нового синтаксиса.
---
Как совершенно справедливо заметили участники обсуждения в Сообщении 10 и 16, при простом («штатном») переходе на SQL проведение документов может существенно замедлиться. Это связано с тем, что штатные механизмы 1С 7.7 накладывают избыточные блокировки на таблицы СУБД и генерируют неоптимальные запросы.
Проанализируем методы оптимизации работы 1С 7.7 на SQL:
Перевод критических участков на «прямые запросы» (1С++)
Внешняя компонента 1С++ позволяет полностью отказаться от тяжелых штатных механизмов работы с регистрами (таких как метод Рег.ВыгрузитьИтоги()) и выполнять запросы к СУБД напрямую через T-SQL.
Рассмотрим пример замены штатного черного запроса на прямой запрос к таблице остатков регистра партий через 1С++:
Запрос = СоздатьОбъект("ODBCRecordset");
ТекстЗапроса = "
|SELECT
| Рег.Номенклатура [Номенклатура $Справочник.Номенклатура],
| SUM(Рег.КоличествоОстаток) Количество,
| SUM(Рег.СуммаРубОстаток) Сумма
|FROM
| $РегистрОстатки.ПартииНаличие(:КонДата,, Номенклатура, Количество, СуммаРуб) AS Рег
|GROUP BY
| Рег.Номенклатура
|";
Запрос.УстановитьПараметр("КонДата", РабочаяДата());
ТаблицаОстатков = Запрос.ВыполнитьИнструкцию(ТекстЗапроса);
Такой запрос выполняется на сервере за доли секунды, тогда как штатный обход регистра на большой базе может подвесить систему на несколько минут.
Использование ToySQL и ToyBlocking
Внедрение программных комплексов класса ToySQL позволяет заменить штатный транслятор запросов 1С на оптимизированный. Входящий в комплект модуль блокировок ToyBlocking (или аналогичные решения от компании Софтпойнт) переводит блокировки СУБД с уровня таблиц на уровень строк (Row-Level Locking). Это полностью решает проблему «взаимных блокировок» (Deadlocks) при одновременной работе 20 и более активных пользователей в терминале.
Переписывание процедур проведения документов
Как указано в Сообщении 17, для достижения максимального быстродействия необходимо переписать глобальные процедуры списания партий (например, глСписаниеПартийТМЦ и глСписаниеОстатковТМЦ) на прямые запросы. Это убирает циклы и избыточные обращения к базе данных, сводя проведение сложного документа с тысячами строк к нескольким быстрым SQL-операциям.
---
Регулярная обрезка (свертка) базы — классический способ борьбы с ростом DBF. Мы фиксируем дату свертки (например, начало текущего года), получаем остатки на эту дату, формируем документы ввода остатков, а все документы прошлых периодов физически удаляем из базы данных.
Преимущества:
Недостатки (почему обрезка вредит бизнесу):
---
Несмотря на то, что с помощью MS SQL и прямых запросов базу «1С 7.7» можно успешно эксплуатировать еще многие годы, необходимо объективно оценивать стратегические риски:
Поэтому правильным решением будет запланировать переход на современные конфигурации семейства «1С:Предприятие 8» (например, «Управление торговлей 11» или «ERP»). Да, это долго и дорого, особенно если текущая семерка сильно кастомизирована под уникальные бизнес-процессы. Но этот переход неизбежен, и лучше готовиться к нему планомерно, а не в режиме тушения пожара.
---
Подводя итог, сформируем оптимальный план действий в зависимости от критичности ситуации: