Как исправить ошибку 310 и переполнение файла остатков регистра RG в 1С 7.7?

Разберем распространенную критическую ситуацию в файловых информационных базах 1С:Предприятие 7.7: при открытии периода, пересчете итогов или восстановлении последовательности документов программа аварийно завершает работу с ошибкой CodeBase Error #: -310, а размер одного из файлов базы данных (например, RG1130.dbf) превышает 2 ГБ.

Выясним причину такого поведения движка базы данных, проанализируем структуру регистров и рассмотрим по шагам все возможные способы решения проблемы.

Причины возникновения ошибки и роста файла RG

Файловый движок базы данных 1С 7.7 (CodeBase) имеет жесткие технические ограничения:

1. Лимит размера файла в 2 ГБ: из-за использования знаковых 32-битных целочисленных смещений файловый указатель при превышении 2 147 483 647 байт переполняется, что делает дальнейшее чтение и запись невозможными.
2. Лимит количества записей в таблице: ошибка -310 (Not a correct Index File / Corrupt Index File) часто возникает при превышении порога в 16 777 215 ($2^{24}-1$) записей, когда система перестает корректно адресовать элементы индексного дерева .cdx (в частности, по системному тегу IDELETED).
3. Механизм расчета остатков в регистрах: таблица остатков RG*.dbf хранит срезы на начало каждого расчетного месяца. Если в регистре остатков (например, «ПартииТоваров») ведутся только приходные движения без регулярного списания в ноль по всем измерениям (включая конкретный документ партии ПрихДокумент), остатки не закрываются. При наступлении каждого нового месяца платформа дублирует все незакрытые записи прошлых периодов, вызывая лавинообразный рост объема таблицы.

Шаг 1. Идентификация проблемного регистра

Чтобы понять, какая именно таблица вызывает сбой, обратимся к файлу словаря данных 1Cv7.DD, расположенному в каталоге информационной базы. Откроем его любым текстовым редактором и выполним поиск по имени сбойного файла (например, RG1130):

#==TABLE no 89 : Регистр ПартииТоваров
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=RG1130 |Регистр ПартииТоваров |A |RG1130 |1
#-----Fields-------
F=PERIOD |Period Registr |D |8 |0
F=SP2654 |(P)Фирма |C |9 |0
F=SP1131 |(P)Товар |C |9 |0
F=SP1132 |(P)ПрихДокумент |C |13 |0
F=SP1133 |(P)ОстатокТовара |N |16 |5

Таблица RG1130 хранит периодические итоги регистра, а таблица RA1130 — его движения. Наличие уникального разреза ПрихДокумент при отсутствии регулярных расходных накладных приводит к бесконечному разрастанию таблицы итогов.

Вариант 1. Отключение неиспользуемого регистра в коде и очистка таблиц

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

1. Обязательно создадим полную резервную копию каталога информационной базы.
2. Завершим работу всех пользователей и убедимся, что процессы 1cv7s.exe или 1cv7.exe не активны.
3. Удалим физические файлы переполненного регистра из каталога базы данных: RG1130.dbf, RA1130.dbf, а также соответствующие индексные файлы RG1130.cdx, RA1130.cdx.
4. В конфигураторе найдем глобальную процедуру формирования движений по партиям (обычно глДвижениеПартий) и отключим расчет:

Процедура глДвижениеПартий(Контекст, ВремРегистры = 0) Экспорт
    // Полное отключение избыточного партионного учета
    Возврат;
КонецПроцедуры

1. Запустим 1С:Предприятие в монопольном режиме и выполним процедуру «Управление оперативными итогами» (меню «Операции») с пересчетом итогов. Пустые таблицы создадутся заново, а их рост прекратится.

Вариант 2. Очистка и пересчет итогов без отключения движений

Если движения по регистру нужны для истории, но переполнилась именно таблица рассчитанных итогов RG*.dbf, применим процедуру сброса накопленных остатков:

1. Создадим резервную копию базы данных.
2. Удалим из каталога базы все файлы остатков RG*.dbf и индексные файлы *.cdx.
3. Запустим 1С:Предприятие в монопольном режиме. При запуске система автоматически пересоздаст индексные файлы.
4. Перейдем в меню «Операции» — «Управление оперативными итогами» и выполним полный пересчет итогов.
5. Если требуется уменьшить будущий размер таблиц, выполним свертку информационной базы через стандартное архивирование периода либо введем документы списания/инвентаризации, чтобы закрыть зависшие остатки в ноль.

Вариант 3. Оптимизация структуры регистра в конфигураторе

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

1. Откроем Конфигуратор, перейдем в дерево метаданных: «Регистры» — «ПартииТоваров».
2. Удалим измерение ПрихДокумент (партия), оставив только Товар и Фирма.
3. При необходимости изменим тип регистра с остаточного на оборотный (для оборотных регистров доступна периодичность хранения итогов «Год», что многократно сокращает размер таблицы).
4. Сохраним конфигурацию и выполним реструктуризацию данных. Платформа схлопнет строки по одинаковым товарам, уменьшив объем таблицы итогов в десятки раз.

Вариант 4. Переход на клиент-серверную версию (MS SQL Server)

Если учет партий необходим в полном объеме, а документооборот слишком велик для 32-битного файлового движка, единственным системным решением является переход на 1С:Предприятие 7.7 для SQL:

1. Используем модифицированную библиотеку dbeng32.dll или специализированные утилиты для корректного чтения переполненной таблицы и формирования файла выгрузки .zip через конфигуратор.
2. Создадим пустую базу данных на MS SQL Server.
3. В конфигураторе 1С выберем формат хранения «SQL Server», укажем параметры подключения и выполним загрузку данных. Реляционные СУБД не имеют файлового ограничения в 2 ГБ на отдельные таблицы.