← На главную

В процессе работы с распределенными базами данных (УРБД) в 1С:Предприятии 7.7 системные администраторы и программисты часто сталкиваются с необходимостью принудительного изменения номеров пакетов обмена. Разберем детально, как устроена эта система, где хранятся данные и как правильно управлять номерами выгрузок, не нарушая целостность конфигурации.

Понимание структуры хранения номеров обмена

Когда система 1С формирует пакет данных для обмена между узлами, она опирается на значения, хранящиеся в служебных таблицах. Ключевой таблицей, отвечающей за историю выгрузок, является 1SDWNLDS. Однако, как показывает практика, простое редактирование этой таблицы не всегда приводит к желаемому результату, так как система использует комплексный подход к контролю последовательности пакетов.

Важно понимать следующие принципы:

• Взаимосвязь таблиц: Номер исходящего пакета определяется текущим идентификатором dwnldid в 1SDWNLDS. При формировании нового пакета система увеличивает этот счетчик.
• Роль таблицы 1SUPDTS: Эта таблица содержит информацию об изменениях объектов, которые еще не были подтверждены (флаг Acknowledge = 0). Пакет обмена всегда формируется с учетом этих данных. Если вы попытаетесь «обнулить» номер, не учитывая состояние очереди изменений, возникнет конфликт целостности.
• Механизм подтверждения: УРБД в 1С 7.7 работает по принципу «диалога». Каждый узел ведет учет того, какие пакеты были отправлены и получены.

Почему простая замена номера в 1SDWNLDS не помогает?

Часто при попытке изменить номер пакета на «1» система продолжает генерировать пакеты с прежними, большими номерами. Это происходит потому, что:

1. Система анализирует записи в 1SDWNLDS, где direct='O' (исходящие), и находит там последний зарегистрированный номер.
2. Внутренние счетчики могут быть закэшированы в оперативной памяти или зависеть от состояния записей 1SUPDTS.
3. Если в базе остались «неподтвержденные» записи, 1С будет стремиться «дослать» их, используя существующую последовательность нумерации.

Как правильно выполнить сброс нумерации

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

Шаг 1: Анализ записей
Прежде всего, просмотрите содержимое таблицы 1SDWNLDS. Если вы видите там строки, которые мешают процессу, удаление конкретной записи, содержащей последний номер, может заставить систему начать отсчет с единицы. Однако, будьте крайне осторожны: удаление истории приведет к тому, что на другом узле пакеты с «новыми» старыми номерами будут отвергнуты с ошибкой «уже загружалось».

Шаг 2: Синхронизация обоих узлов
Никогда не сбрасывайте номер только в одной базе. Если вы обнулили номер в базе-отправителе, вы обязаны очистить соответствующие записи в базе-получателе. В противном случае, при попытке загрузить пакет №1, система-получатель сравнит его с имеющейся историей и заблокирует процесс из-за несоответствия ожидаемого номера пакета.

Шаг 3: Очистка записей в 1SUPDTS
Если пакеты не уходят или возникают ошибки, проверьте состояние таблицы 1SUPDTS. Если там накопилось множество записей с Acknowledge = 0, которые система пытается включить в пакет, это может блокировать нормальную работу обмена. В крайних случаях, когда обмен полностью разбалансирован, специалисты проводят полную инициализацию узла, что по сути означает удаление всех записей обмена и повторную первичную выгрузку.

Технические рекомендации

Для минимизации рисков при работе с системными таблицами УРБД, придерживайтесь следующих правил:

• Всегда делайте резервную копию базы данных перед любыми манипуляциями с системными таблицами формата DBF или SQL.
• Используйте штатные механизмы: по возможности, избегайте прямого редактирования таблиц. Иногда достаточно пересоздать настройку обмена в конфигураторе, чтобы система обнулила внутренние счетчики корректно.
• Контролируйте файлы обмена: после сброса номеров обязательно очистите каталог обмена от старых файлов выгрузок, чтобы избежать путаницы при загрузке.

Разбирая ситуацию, мы выяснили, что 1С 7.7 достаточно консервативна в вопросах обмена. Любая попытка «обмануть» счетчик вручную требует зеркальных действий на стороне партнера. Если же проблема сохраняется даже после манипуляций с таблицами, проанализируйте, нет ли в системе «зависших» пакетов, которые требуют ручного подтверждения получения.