В процессе обновления нетиповой ИБ выходит ошибка:
Ошибка возникает на этапе обновления конфигурации базы данных.
Начнём с того, что мне посоветовали:
- Выгрузить/загрузить базу
- Выгрузить/загрузить .сf
- Провести «Тестирование и исправление информационной базы»
Первые 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
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Интересная статья.
Тоже вышла ошибка при переходе с релиза УПП 1.3.73.2 на 1.3.74.1,но платформа 1С:Предприятие 8.2 (8.2.19.130).
Ошибка была следующего характера «Код справочника стал не уникальным: Статьи калькуляции (0)».
Хотя данный справочник не используется по причине того, что он связан настройкой «Государственные контракты», которые не ведутся в организации.
(1) alexks321, аналогично вышла. И тоже не используется. Это не критичная ошибка, в случае чего просто нужно будет изменить код.
Описанная в статье ошибка — со справочником ВидыДокументов — не выходит при обновлении типовой УПП 1.3.73.2 на 1.3.74.1 на платформе 8.2.19.90 и 8.2.19.83. А насчет уникальности кода статьиКалькуляции предупреждение — выходит.
(2) Конечно, так и сделал, просто проигнорировал это предупреждение, но остался осадок, а все ли верно прошло с обновлением. О таких вещах можно было и предупрелить, особно осторожных, что это штатная ситуатция.
Спасибо за статью! Вылетела эта же ошибка при обновлении УПП.
(5) wano37, рад помощь)
Интересный подход по решению неочевидной проблемы. Надо взять на заметку. Однозначно плюс.
Спасибо за информацию. Однозначно может пригодится. Еще не натыкался на такую ситуацию а уже один из вариантов решения если что будет в запасе..)
Ащее респект! Столько времени сэкономил! Благодарен очень)
Спасибо, столкнулся с такой же проблемой.
спасибо за помощь! А вообще хотелось бы узнать более правильный способ нахождения такой ошибки…
(11) alexnov, мне кажется если обновить на более новом релизе платформы, то этой ошибки не будет — может это более правильный способ, но и указанный способ вполне безопасен.
Большое спасибо за то, что поделились опытом! Сэкономил кучу времени…
Спасибище, только представил себе как это всё самому искать, это ж целый день запросто угробить можно.
Добавлю (спустя еще год).
После обновления при проведении конкретного документа вылезло аналогичное. «Ошибка SDBL» тип «»»» не совпадает с типом поля Bl00909200
Вылезло после обновления. Тестирование и исправление останавливается именно на таблице этого документа. В конфигураторе обнаруживаю единственный реквизит, вставленный программистами. И тип реквизита после обновления вместо типа «Документ» стал типом «Строка».
Поменял на нужное — все исправилось. Повезло, что потерянные данные не критичны для работы.
Присоединяюсь. Респект автору. То же УПП те же релизы платформы и конф. Единственное после изменения типа кода с строки на число, при обновлении опять ругнулась: В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 10.0: Не удается вставить повторяющуюся строку ключа в объект «dbo._ReferenceChngR2121NG» с уникальным индексом «_Refere2121_ByDataKey_RRNG». Повторяющееся значение ключа: (0x97b6002590a25f6611e5aec6c6ce632f, 0x00000012, 0x97b9002590a25f6611e61201af44237e).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1
В этом же справочнике удали все предопределенные элементы. Затем в режиме приложения удалил помеченные объекты. Затем провел обновление, все норм.
Интересно, какие особенности эксплуатации заставляют пользоваться столь древней платформой? Даже на момент написания статьи…
Для описания подобного рода ошибок следует делать проверку на последних версиях, чтобы понимать является ли это особенностью конкурентной версии.
(17) вот и сделайте, кто вам мешает? Все данные есть, номера релизов есть проверяйте.
Позвольте мне самому решать, что «следует» «Для описания подобного рода ошибок» делать.
Не нравится не читайте, правила сайта соблюдены. А то нашелся тут, советчик, который советует как делать публикации, а сам при этом не имеет ни одной.
(18) Зачем так критично. Ошибка интересная. Я, например, с ней не встречался.
Почему упомянул об обновлении платформы? Потому что не исключено, что это может быть исправленный баг старых версий. Тогда правильный вывод из публикации будет не «знайте эту ошибку и вот вам метод как ее исправить», а «вовремя обновляйте платформу для исправления известных ошибок». Такие вопросы напрашиваются сами собой.
За публикацию и однозначно спасибо. На то и открытые комментарии, чтобы в спорах родить/узнать истину.
Вы хотели только хвалебные комментарии? ))) Их нещадно заминусуют как творение ботов )
да уж… Не нашел пока в себе мотивации. И до сих пор не знаю для чего это другие делают (слава? деньги? некуда время девать?).
При обновлении типовой УПП 1.3.73.2 на 1.3.74.1 на платформе 8.3.8.2322 — стали неуникальными коды предопределенных элементов справочника статьи калькуляции, который не используется.
А вот других ошибок на этом обновлении — не было.
Ну вот на дворе 2019 год, платформа 8.3.13.1809, обновляю без дважды измененных свойств бухгалтерию Проф на версию Корп, того же релиза. Выскакивает ошибка SDBL с указанием некого Document34 и поля Parent — но такого в базе данных нет… да и какой у документа Parent…
уже даже отказался от доработок и привёл к типовому виду. Обновляю уже без сравнения — всё равно Выскакивает ОШИБКА SDBL уже без каких-либо вообще дополнительных слов…сейчас делаю ТиИ сообщилась ошибка
Тестирование начато
Проверка логической целостности. Справочник.ФизическиеЛица М****в Юрий Николаевич
ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
Неправильная ссылка на родителя. Перенесен в корень.
Тестирование закончено
Вроде как про родителя речь… надеюсь в этом было дело… обновляю теперь опять на корп… посмотрим что будет
(21) продолжение
Обновление прошло без ошибок в конфигураторе, а вот в режиме предприятия такое сообщение…
(22) продолжение
В общем сделал тестирование и исправление — реструктуризацию и реиндексацию. База выросла с 9 гб до 12 гб. Но ошибка ушла — всё хорошо обновилось