Работа с платформой 1С:Предприятие 7.7 в современных условиях требует особого внимания к объему данных и стабильности движка DBF. Одной из самых загадочных проблем является ситуация, когда регламентная обработка выгрузки остатков (например, в интернет-магазин) годами работает штатно, но вдруг начинает выдавать неполные данные: например, выгружает остатки только по двум складам из четырех. Разберем детально причины этого поведения и методы радикального лечения системы.
Первым делом проанализируем, почему штатный программный код может игнорировать склады, жестко прописанные в списке. Проблема часто кроется не в логике 1С, а в особенностях работы файлового движка при высокой нагрузке.
Запрос может пропустить часть записей в RG* (таблицы итогов) или RA* (таблицы движений) и завершиться без ошибок, просто вернув неполный результат.1SCONST.DBF: Обращение к Константа.ОсновнойСклад напрямую в цикле или при инициализации — потенциальное узкое место. Если таблица констант заблокирована другим процессом, чтение может отработать с задержкой или сбоем.ПриОткрытии, затирая ваши программно добавленные склады.Посмотрим на размеры файлов в каталоге базы. Если вы видите, что файлы итогов регистров (RG*) значительно превышают размеры файлов движений (RA*), это явный признак «незакрытых» регистров. Проанализируем, почему это критично.
В идеальной ситуации, когда остаток товара становится нулевым, запись в таблице RG должна обнуляться или исчезать. Однако, если в конфигурации есть ошибки проектирования (например, по приходу пишется одна Карточка, а по расходу — другая, или не закрываются ресурсы типа Сумма), таблица итогов начинает «пухнуть». Система при каждом запросе остатков вынуждена перебирать миллионы «нулевых» записей, что приводит к деградации производительности и тем самым сбоям в выборке.
Выясним причину разрастания с помощью прямого запроса к итогам бухгалтерских счетов (используя 1SQLite или 1C++):
SELECT
ACCS.SCHKOD AS Счет,
count(*) AS КоличествоЗаписей
FROM __1S_BKTTL AS BKTTL
LEFT JOIN __1S_ACCS ACCS ON ACCS.ID = BKTTL.ACCID
GROUP BY ACCS.SCHKOD
ORDER BY КоличествоЗаписей DESC
Этот запрос покажет нам, какой именно счет или регистр вносит максимальный вклад в объем файла 1SBKTTL.DBF. Часто виновниками оказываются счета взаиморасчетов (60, 62), где ведется учет в разрезе документов, которые никогда не закрываются в ноль.
Рассмотрим пример из практики: в регистре остатков ТМЦ есть ресурс Сумма. Если при приходе туда записывается себестоимость, а при расходе — цена продажи, то регистр по количеству закроется, а по сумме — нет. В итоге в базе копятся миллионы записей с «зависшей» прибылью, которые 1С тащит из периода в период.
Правильное решение:
Резерв или СуммаПродажи) вам не нужны итоги на конец периода в разрезе всех измерений, перенесите этот показатель из Ресурсов в Реквизиты регистра.Если файл 1SBKTTL.DBF (бухгалтерские итоги) или 1SENTRY.DBF (проводки) приблизился к отметке в 2 Гб, стандартный движок dbeng32.dll может начать вести себя неадекватно. Разберем шаги по спасению базы:
dbeng32.dll (например, от автора Wirth), который позволяет работать с файлами размером более 2 Гб за счет иного способа адресации. Это позволит базе «дышать» во время проведения свертки.vk_TerminalSleep или соответствующие патчи движка, чтобы снизить нагрузку на процессор при ожидании блокировок.1C++. Прямое чтение таблиц DBF минуя объект Запрос работает на порядок быстрее и не страдает от «пропусков» при транзакциях.Когда база достигает критических размеров, обычное удаление документов через Документ.Удалить(1) не поможет — система просто «захлебнется» в индексах. Проанализируем алгоритм быстрой свертки:
Шаг 1: Подготовка данных. Создайте специализированные документы ввода остатков. Заполните их программно на дату свертки (например, на 1 января текущего года). Важно: не проводите эти документы сразу, просто запишите их.
Шаг 2: Очистка таблиц. Самый эффективный способ — прямое удаление. После создания документов остатков и создания архивной копии базы, можно воспользоваться обработками на базе прямых запросов для удаления записей из 1SJOURN, 1SENTRY, 1SOPER и таблиц движений регистров RA* по условию даты.
Шаг 3: Сброс итогов. После физического удаления движений необходимо «обнулить» таблицы итогов. Посмотрим на последовательность действий:
RG* (итоги регистров) и 1SBKTTL* (бухгалтерские итоги) из каталога базы.Чтобы минимизировать влияние «глюков», перепишем фрагмент выгрузки, добавив логирование и защиту от перезаписи настроек. Проанализируем следующий пример:
Процедура ПриОткрытии()
Если Форма.Параметр = "ЭкспортНочью" Тогда
// Очищаем список, чтобы исключить влияние сохраненных настроек
ВыбСклад.УдалитьВсе();
// Используем ЗначениеИзСтрокиВнутр для надежности, если константы нестабильны
// Либо просто перечисляем идентификаторы, если конфигурация позволяет
ВыбСклад.ДобавитьЗначение(Константа.ОсновнойСклад);
ВыбСклад.ДобавитьЗначение(Константа.Склад1);
// Записываем в Журнал Регистрации начало процесса
ЗафиксироватьУзел("Начало выгрузки. Складов в списке: " + ВыбСклад.РазмерСписка());
Попытка
ЭкспортВсехТМЦ();
ЗафиксироватьУзел("Выгрузка завершена успешно");
Исключение
ЗафиксироватьУзел("Ошибка выгрузки: " + ОписаниеОшибки());
КонецПопытки;
// Закрываем форму без сохранения изменений
СтатусВозврата(0);
Возврат;
КонецЕсли;
КонецПроцедуры
Посмотрим, что мы изменили: мы добавили явное логирование количества складов перед началом работы. Теперь, если в логе будет написано «Складов в списке: 4», а выгрузится 2 — проблема в запросе и итогах. Если в логе будет «Складов в списке: 2» — проблема в инициализации или настройках формы.
Подводя итог, можно сказать, что «глюки» в 1С 7.7 на больших базах — это почти всегда следствие физических ограничений формата DBF или логических ошибок в структуре регистров, которые приводят к бесконечному росту итогов. Своевременная свертка и переход на современные методы работы с данными (прямые запросы) позволяют эксплуатировать систему даже при очень больших объемах товарооборота.