Проблема «пустого обмена» в системе распределенных баз данных (УРБД) на платформе 1С 7.7 — это классическая ситуация, с которой сталкиваются администраторы и программисты при эксплуатации крупных сетей. Суть проблемы заключается в следующем: в периферийной базе (ПБ) зафиксированы изменения объектов, таблица регистрации изменений заполнена, процесс выгрузки проходит без видимых ошибок, но результирующий файл обмена содержит только заголовок и оказывается практически пустым. Разберем по шагам, почему это происходит и как восстановить нормальную работу системы.
Для начала проанализируем, как 1С 7.7 понимает, какие данные нужно включить в файл выгрузки. Основную роль здесь играют две системные таблицы: 1SUPDTS (таблица регистрации изменений) и 1SDWNLDS (таблица сессий обмена).
В таблице 1SUPDTS хранятся ссылки на все измененные объекты. Ключевым полем для нас является DWNLDID. Рассмотрим логику его работы: когда мы запускаем процесс «Выгрузить данные», система помечает все текущие записи в 1SUPDTS уникальным номером сессии в поле DWNLDID. Параллельно в таблице 1SDWNLDS создается запись с этим же номером, фиксирующая начало сессии выгрузки для конкретной базы.
Выясним причину, по которой данные могут игнорироваться. Если предыдущий сеанс обмена завершился аварийно (например, из-за выключения света, сбоя сети или нехватки места на диске), записи в 1SUPDTS остаются помеченными старым идентификатором DWNLDID. При следующей попытке выгрузки 1С ищет только те записи, где DWNLDID = 0. Записи со «старыми» ID она считает уже отправленными, но еще не подтвержденными, и в новый файл не включает. Если новых изменений с момента сбоя не было, файл будет пустым.
Если мы обнаружили, что в 1SUPDTS есть данные, но их поле DWNLDID заполнено значениями, которых нет в актуальных записях 1SDWNLDS, нам необходимо «сбросить» это состояние. Проанализируем алгоритм действий:
DWNLDID.UPDATE 1SUPDTS SET DWNLDID = 0 WHERE DESTID = 'ID_ВАШЕЙ_ЦБ'.После обнуления система увидит эти записи как новые и при следующей выгрузке сформирует полноценный файл с данными.
Другой критически важный фактор — идентичность конфигураций в центральной и периферийной базах. Рассмотрим ситуацию, когда в центральной базе (ЦБ) были внесены изменения в структуру данных. В этом случае 1С 7.7 включает в файл обмена обновленный 1CV7.MD.
Важный момент: пока периферийная база не примет этот файл, не обновит свою конфигурацию и не отправит обратно в ЦБ подтверждение (квитанцию) о том, что структура теперь совпадает, обмен данными может быть заблокирован. ПБ будет генерировать пустые файлы, ожидая корректного завершения цикла обновления. Если у вас «70% дочек» перестали присылать данные после обновления центра, значит, они либо еще не загрузили новый MD, либо загрузили его некорректно, либо не отправили ответный пакет с подтверждением версии.
Иногда корень проблемы кроется в настройках конфигуратора. Проанализируем свойства объектов. У каждого документа или справочника в 1С 7.7 есть свойство «Миграция». Если установлено значение «Место создания», то объект, созданный в ЦБ, попадет в ПБ, но любые изменения этого объекта в ПБ никогда не улетят обратно в центр. Если вы ожидаете данные от дочерних баз по объектам, которые были созданы не у них, проверьте, стоит ли в правилах миграции значение «Все базы».
Не забудем и про физическое состояние файлов базы данных. В платформе 7.7 (особенно в DBF-версии) часто случаются повреждения индексных файлов .cdx. Рассмотрим последовательность технического обслуживания:
.cdx файлы в каталоге базы и запустить 1С снова для их полной перегенерации.Также стоит проверить размер файлов 1SUPDTS.DBF и 1SDWNLDS.DBF. Если их размер приближается к критическим 2 ГБ, механизм УРБД может начать вести себя непредсказуемо, включая генерацию пустых пакетов.
В этой таблице хранятся номера принятых и отправленных сообщений для каждой информационной базы. Посмотрим, как это влияет на процесс: если ПБ считает, что она уже отправила пакет №100, а ЦБ ждет пакет №90, может возникнуть коллизия. Проанализируем ситуацию: иногда помогает принудительное уменьшение номера ожидаемого сообщения в ЦБ для конкретной дочерней базы, чтобы инициировать повторный запрос данных. Однако делать это стоит осторожно, понимая структуру системы.
Подводя итог, можно сказать: если обмены «упали», в первую очередь проверяйте идентичность MD-файлов во всей сети и чистоту поля DWNLDID в регистрах изменений. Сочетание этих двух факторов решает 90% проблем с пустыми файлами в УРБД 7.7.