gifts2017

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

Опубликовал Руслан Эскин (Anesk) в раздел Администрирование - Тестирование и исправление

В этой статье описан способ решения ошибки "В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка 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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Ахтямов Альберт (alexks321) 16.03.16 14:48
Интересная статья.
Тоже вышла ошибка при переходе с релиза УПП 1.3.73.2 на 1.3.74.1,но платформа 1С:Предприятие 8.2 (8.2.19.130).
Ошибка была следующего характера "Код справочника стал не уникальным: Статьи калькуляции (0)".
Хотя данный справочник не используется по причине того, что он связан настройкой "Государственные контракты", которые не ведутся в организации.
2. Руслан Эскин (Anesk) 16.03.16 15:03
(1) alexks321, аналогично вышла. И тоже не используется. Это не критичная ошибка, в случае чего просто нужно будет изменить код.
3. Александр Капустин (kapustinag) 16.03.16 18:55
Описанная в статье ошибка - со справочником ВидыДокументов - не выходит при обновлении типовой УПП 1.3.73.2 на 1.3.74.1 на платформе 8.2.19.90 и 8.2.19.83. А насчет уникальности кода статьиКалькуляции предупреждение - выходит.
4. Ахтямов Альберт (alexks321) 18.03.16 07:28
(2) Anesk, Конечно, так и сделал, просто проигнорировал это предупреждение, но остался осадок, а все ли верно прошло с обновлением. О таких вещах можно было и предупрелить, особно осторожных, что это штатная ситуатция.
5. Иван М (wano37) 21.03.16 23:26
Спасибо за статью! Вылетела эта же ошибка при обновлении УПП.
6. Руслан Эскин (Anesk) 22.03.16 07:06
7. Андрей Щеглов (Andrefan) 23.03.16 08:50
Интересный подход по решению неочевидной проблемы. Надо взять на заметку. Однозначно плюс.
pioneeer; +1 Ответить
8. Dmitriy (daho) 24.03.16 15:23
Спасибо за информацию. Однозначно может пригодится. Еще не натыкался на такую ситуацию а уже один из вариантов решения если что будет в запасе..)
pioneeer; +1 Ответить
9. Сергей (pioneeer) 06.04.16 17:23
Ащее респект! Столько времени сэкономил! Благодарен очень)
10. Игорь (igorbel) 13.04.16 10:21
Спасибо, столкнулся с такой же проблемой.
11. Alex Newman (alexnov) 14.04.16 13:38
спасибо за помощь! А вообще хотелось бы узнать более правильный способ нахождения такой ошибки...
12. Руслан Эскин (Anesk) 14.04.16 15:26
(11) alexnov, мне кажется если обновить на более новом релизе платформы, то этой ошибки не будет - может это более правильный способ, но и указанный способ вполне безопасен.
13. Андрей Лукин (frkbvfnjh) 02.08.16 11:35
Большое спасибо за то, что поделились опытом! Сэкономил кучу времени...
14. luchyk (luchyk) 21.10.16 10:54
Спасибище, только представил себе как это всё самому искать, это ж целый день запросто угробить можно.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа