Как исправить ошибку «Размер потока не соответствует заявленному» и убрать мусор из файла MD в 1С 7.7?

В процессе длительной разработки и многократного объединения конфигураций в 1С 7.7 разработчики часто сталкиваются с накоплением скрытого «мусора» в файле метаданных 1Cv7.MD. Это проявляется в виде постоянных ложных сообщений об изменении диалогов форм при сравнении конфигураций, ошибок утилит проверки целостности метаданных (например, MDDiags сообщает: «Размер потока не соответствует заявленному»), а также появления зависших временных таблиц в базе данных SQL. Разберем подробно внутреннее устройство файла конфигурации, причины возникновения этих проблем и пошаговые методы их устранения.

Причины повреждения потока Dialog Stream и расхождения диалогов

Файл конфигурации 1Cv7.MD представляет собой структурированное OLE-хранилище (формат Compound File). Ошибка «Размер потока не соответствует заявленному» в потоках Dialog Stream и постоянные ложные срабатывания при сравнении возникают по следующим причинам:

1. Специфика формата OLE DocFile: при многократных правках и объединениях конфигураций фактический размер бинарного потока элементов диалога может разойтись с длиной, зафиксированной в оглавлении каталога WorkBook. В потоке остаются так называемые хвостовые байты (trailing bytes) от удаленных реквизитов и слоев.
2. Влияние системных настроек ОС: механизм сравнения диалогов в Конфигураторе 7.7 выполняет побитовое сравнение графического представления формы. Разрешение экрана, масштаб шрифтов и темы оформления Windows (например, классическая тема против современных визуальных стилей) приводят к микросмещениям координат элементов и вызывают ложные флаги изменений.
3. Спецсимволы в свойствах контролов: наличие незаэкранированных кавычек или скрытых управляющих символов в подсказках, формулах кнопок и текстовых заголовках нарушает работу внутреннего парсера 1С.

Способы устранения ошибок в потоках диалогов

Проанализируем практические методы восстановления корректной структуры форм и удаления мусорных данных из 1Cv7.MD.

Метод 1. Принудительная перегенерация формы в Конфигураторе

Самый простой и безопасный способ заставить платформу пересчитать заголовок и тело потока Dialog Stream:

1. Откроем проблемный объект (например, справочник «Сотрудники») в дереве метаданных Конфигуратора.
2. Перейдем в редактор диалога формы элемента или списка.
3. Выделим любой визуальный элемент, сдвинем его на один пиксел в сторону и вернем обратно на исходную позицию. Это действие выставит внутренний флаг модифицированности формы.
4. Сохраним конфигурацию. При полной перезаписи диалога Конфигуратор заново формирует бинарный поток, устраняя несоответствие заявленного размера.

Метод 2. Декомпиляция и нормализация сорцов через GComp

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

1. Выполним разборку исходного файла метаданных на составные модули и описания форм.
2. Применим скрипт нормализации диалогов (например, correct_dlg.pl), который выравнивает координаты контролов, очищает лишние пробелы и приводит структуры к единому виду.
3. Соберем конфигурацию заново. При сборке GComp создает новое чистое OLE-хранилище без фрагментации и мусорных секторов.

Метод 3. Реструктуризация и дефрагментация файла 1Cv7.MD

Удаление объектов в 1С 7.7 не уменьшает физический размер файла 1Cv7.MD, так как OLE-контейнер не освобождает секторы автоматически. Чтобы очистить контейнер, выполним пересохранение:

1. Создадим резервную копию базы данных.
2. В Конфигураторе выберем пункт меню Конфигурация → Сохранить конфигурацию в файл... и сохраним копию метаданных.
3. Выполним операцию Конфигурация → Загрузить измененную конфигурацию..., указав сохраненный файл.
4. При полной перезаписи размер файла 1Cv7.MD существенно уменьшается, а внутренние таблицы словаря метаданных перестраиваются.

Почему различаются имена SQL-таблиц и откуда берутся таблицы с суффиксом _NEW

При анализе структуры СУБД в разных базах можно заметить две особенности: разные числовые префиксы (например, SC100 в одной базе и SC200 в другой) и наличие таблиц вида SC70_NEW, DT38204_NEW.

Разберем природу этих явлений:

1. Числовые идентификаторы (ObjID): имя физической таблицы в SQL формируется из префикса типа объекта (SC — справочник, DH/DT — шапка и табличная часть документа, RG/RA — регистры) и внутреннего уникального ID объекта. Если справочник создавался в базах независимо, его внутренний ID будет отличаться. Попытка накатить метаданные прямой загрузкой из другой базы при несовпадении ID приведет к потере данных, так как платформа попытается удалить старую таблицу и создать пустую с новым ID. Для выравнивания структуры между разными базами данные переносят через правила конвертации или внешние обработки выгрузки/загрузки.
2. Таблицы с суффиксом _NEW: эти таблицы представляют собой следы аварийно завершенной реструктуризации. При изменении структуры метаданных 1С 7.7 создает временную таблицу с постфиксом _NEW, копирует туда данные с преобразованием типов, удаляет старую таблицу и переименовывает временную. Если в процессе сохранения произошел сбой (отключение питания, зависание процесса, разрыв сети), временная таблица остается в базе.

Безопасная очистка зависших таблиц _NEW в SQL Server

Перед удалением временных таблиц необходимо убедиться, что они действительно являются мусорными, а не содержат единственную копию актуальных данных после сбоя переименования.

Проанализируем состояние таблиц следующим SQL-запросом:

-- Поиск всех временных таблиц реструктуризации в базе
SELECT 
    t.name AS TableName, 
    p.rows AS TotalRows
FROM sys.tables t
INNER JOIN sys.partitions p ON t.object_id = p.object_id
WHERE t.name LIKE '%_NEW' AND p.index_id IN (0, 1)
ORDER BY t.name;

Выполним проверку по шагам:

1. Сравним количество записей в основной таблице (например, SC70) и временной (SC70_NEW). Если основная таблица существует и содержит актуальные данные, а в таблице _NEW данных нет или они дублируются, временную таблицу можно безопасно удалить.
2. Если основная таблица отсутствует или пуста, а данные находятся в таблице _NEW, необходимо вручную переименовать _NEW в имя основной таблицы.
3. После удаления всех неиспользуемых таблиц _NEW запустим Конфигуратор в монопольном режиме и выполним полное Тестирование и исправление информационной базы с проверкой физической целостности и реиндексацией.