Каталог решений - В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка SDBL: Тип поля Code несовместим с типом литерала STRING

В процессе обновления нетиповой ИБ выходит ошибка:

Ошибка возникает на этапе обновления конфигурации базы данных.

Начнём с того, что мне посоветовали:

1. Выгрузить/загрузить базу
2. Выгрузить/загрузить .сf
3. Провести «Тестирование и исправление информационной базы»

Первые 2 пункта мне не помогли, а ТиИ именно на проверке логической целостности вываливается со следующей ошибкой:

Причину этой ошибки выявить не удалось, как и загрузить в файловую версию, т.к. 2 таблицы (

AccumRg27945 — это РегистрНакопления.ЗатратыНаВыпускПродукцииНалоговыйУчет

AccumRg27891 -РегистрНакопления.ЗатратыНаВыпускПродукцииБухгалтерскийУчет) превышают 4 гига.

Буду рад услышать в комментариях ваше мнение по решению этой, уже другой ошибки. Конечно, не очень хотелось заниматься сворачиваем этих регистров ради выгрузки в файловую версию ради проведения ТиИ, а просто заставить ТиИ работать на клиент-серверной версии. А всё началось просто с ошибки обновления. Вернемся к ней…

Предположив, что ошибка обновления выходит из-за конкретного документа, справочника или другого объекта, проводим обновления методом исключения, т.е. при сравнении\объединении без фильтрации по дважды измененным свойствам снимаем галочки с половины объектов. Если обновление проходит успешно, значит, ошибка в другой половине, если с ошибкой, значит, в этой половине.  Затем эту половину снова делим на 2 и т.д.

В результате недельного труда, виновником оказался Справочник.ВидыДокументов, он же «Виды подтверждающих документов».

Немного об этом справочнике: «Виды подтверждающих документов» — предназначен для хранения типов документов, которые участвуют в системе электронного обмена подтверждающими документами с уполномоченным банком, что позволяет банку ускорить процесс проверки платежных поручений.

Типовой справочник, который появился в предыдущем обновлении месяц-два назад. Самое интересное что он в текущей базе не используется, потому что организация не занимается государственными контрактами и в настройке параметров учета эта функциональность отключена. Всё, что там есть — это предопределенные элементы.

В моей базе справочник типовой, но при сравнении/объединении показывает что будто бы изменили динамический список в форме списка справочника.

Получается, если просто снять галочку с этого справочника, т.е. не обновлять справочник, то обновление пройдёт успешно. Но помнить о том, что нужно снимать галочку каждый раз, когда поставщик вносит изменения, не лучшее решение.

Делаем запрос и ищем странности в этом справочнике:

Из странностей видим только то, что в коде одного из элементов куча пробелов, проверяем в основной конфигурации и старой конфигурации поставщика — там тоже эти лишние пробелы, а в новой конфигурации поставщика нет пробелов.

Далее смотрим, какие же изменения вносит поставщик:

Видим, что поставщик уменьшил длину кода с 9 до 3, но самое интересное тут то, что поставщик изменил тип кода со «строки» на «число». Видимо, именно об этом и говорит ошибка «Тип поля Code несовместим с типом литерала STRING». Получается, платформа меняет тип кода, а потом не может записать строковые коды предопреденных элементов в числовое поле. Или что там в какой последовательности, я точно не знаю.

Проверяем. В конфигураторе включаем возможность редактирования справочника, переводим тип кода в числовой тип. Обновляем конфигурацию БД.  Тип кода сменился без ошибок, а значит, коды предопределенных элементов преобразовались без ошибок.

Теперь накатываем обновление поставщика, видим, что тип кода и его длина не участвуют в обновлении, потому что совпадают, зато участвуют предопреденные элементы.

Обновление прошло успешно! Теперь осталось дождаться выходных и накатить это на рабочую базу.

И последнее, о чем следует упомянуть, это то, что все эти действия выполнялись на платформе 1С:Предприятие 8.3 (8.3.5.1248), при переходе с релиза УПП 1.3.73.2 на 1.3.74.1