1с в процессе обновления информационной базы произошла критическая ошибка
Не подскажете как откатиться в обновлении конфигурации?
То есть она обновлена. Но по кнопке обновить конфигурацию базы данных обновления ещё не приняты.
Пока я запустил ТиИ.
(10) Это конечно я делал. И там все проходило успешно.
При ТиИ вышла ошибка, - "Ошибка обращения к серверу".
(15) Я начал обновление УТ на 10 релизов, после каждого обновления запускаю 1с предприятие, и про доделываю успешно обработки обновления дополнительные.
Пока внизу написано реструктуризация, такого то регистра сведений.
Да я не знаю, вот и спрашиваю, что бы подсказали кому известно.
Однажды я сделал копию ДТ, затем протестировал базу и ей пришла хана, а потом ДТшник не загрузился.
С тех пор я делаю ДТ только для перемещения между файловой и серверной базой
(24) памяти добавь. и на другой платформе пробуй.
только не на 14й, там постоянно так ие глюки.
(33) вот ты спросил! если б он знал, неужели, не упомянул бы в (0) об этом?!
(22) +100500. С бэкапом оно каждый может. А вы без рискните.
(37) Вернись на предыдущий релиз из архива, который есть и начинай заново. Но можно начать новую ветку на форуме,если не понял.
Еще раз повторюсь. База легко проходит обновление в файловом режиме. Это проблема не данной базы, а что-то системное.
С данной проблемой уже столкнулся у двух разных клиентов. Платформы разные 8.3.12.1685 и 8.3.13.1644. Объединяет их только использование postgresql. На Ms SQL не пробовал.
Да, обновление кривое, видимо. Даже на демо-базе такую же ошибку выдает. Да, на Postgre. В файловом варианте все норм. На боевую базу его решил не ставить. Кстати, уже есть 11.4.8.82.
(38) Так и хотели сделать. И остановиться на 11_4_7_150
Но сейчас какие то ошибки пошли и в старой версии базы данных.
Там postgre sql.
может, как это бывает, проблема в разрядности платформы? и там, где используют 64 битную, то у всех все нормально и не жалуются на такую ошибку?
Пробовал обновлять на SQL тоже выскакивает ошибка
"Ошибка при получении значения из базы данных. Возможной причиной является отсутствие установленного Microsoft SQL Server Native Client."
В итоге методом исключения нашел что не нужно обновлять справочник "НаборыДополнительныхРеквизитовИСведений", там косяк при изменение имен предопределенных элементов.
Без его изменений обновление ставится.
У нас проблема с обновлением конфигурации 1С ERP c версии с 2.4.8.63 на версию 2.4.8.82 (а так же пробовали на версию 2.4.8.79).
Выходит ошибка одна и та же ошибка в обоих вариантах обновления:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
ERROR: unexpected EOF in COPY data
CONTEXT: COPY _reference289_vt69912ng, line 1, column _fld69915
Клиент-серверный вариант
Платформа 8.3.12.1685
Это, конечно, не УТ, но весьма сходные ошибки. Будем пробовать без указанного справочника. Возможно, так же связано с этим справочником и в ERP.
Накатили обновление без справочника "НаборыДополнительныхРеквизитовИСведений".
Написал в ТП 1С, что ответят по этому поводу.
Update:
Ответ от техподдержки 1С: прислать лог технологического журнала rphostXXX.log. Повторяем обновление, высылаем лог, ждем ответа.
Пришел ответ от 1С:
Обновить платформу до 8.3.15 и postgre до 10.
Будем осуществлять на тестовом сервере.
(53) Я стараюсь из такой ветки только 8.3.12.1790 использовать. Но в продуктиве у меня ее уже нет.
Продуктив сейчас на 8.3.14.1779
А в тестовую машину уже поставил 8.3.15.1489
Обновили на тестовом сервере платформу до последней 8.3.15.1489.
Обновили PostgreSQL до последней версии 10.5-24.1.
Обновление конфигурации устанавливается без ошибок.
Будем в ближайшее время тестить эту платформу.
Если у кого-то уже есть инфа по ней - прошу отписаться.
При обновлении конфигурации может возникнуть очень неприятная вещь!
В процессе обновления информационной базы произошла критическая ошибка по причине:
Попытка вставки неуникального значения в уникальный индекс: Далее текст самой ошибки.
Эту ошибку устранить довольно легко! А как, читайте дальше.
Предыстория
Тут все ясно. Записи стали неуникальными, нужно их удалить!
Самой простой способ это:
Таким методом мы очистим регистр в 1С очень быстро (но это будет и нашей ошибкой).
Ошибка
Казалось бы, в регистре пусто, и можно обновлять 1С. Не хочу вас удивить, но будет снова ошибка:
Что же представляет ошибка:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name 'dbo._InfoRgChngR34546NG' and the index name '_InfoR34546_ByNodeMsg_RNTSRRRRRRNG'. The duplicate key value is (0x00000011, 0x80ca00155d03c00d11e54af2ae5400d7, , Sep 27 4015 10:22PM, 768404, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
Пояснение
А теперь поясню, что же произошло. Когда мы загрузили данные в регистр, то в SQL они попали в таблицу " _InfoR34546". Когда мы кодом в 1С очистили таблицу, то эти данные удалились из таблицы " _InfoR34546", но они скопировались в таблицу " _InfoRgChngR34546". Это и стало проблемой.
Решение
Для решения возникшей проблемы нам понадобится очистить SQL таблицу " _InfoRgChngR34546".
Расскажу на примере "Microsoft SQL Server Management Studio". Заходим в " Management Studio". Находим нашу базу, открываем вкладку таблиц, кликаем на любую и жмем кнопку "Новый запрос": . Теперь набираем запрос
Ошибка "В процессе обновления информационной базы произошла критическая ошибка" в пустую конфигурацию. 1С:Предприятие 8.3 (8.3.13.1513), режим совместимости 8.2. При загрузке конфигурации(.cf) в пустую базу и попытке обновить, получал ошибку: "В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка при попытке вставки записи с неуникальным значением ссылки."
Ошибка "В процессе обновления информационной базы произошла критическая ошибка" в пустую конфигурацию
1С:Предприятие 8.3 (8.3.13.1513), режим совместимости 8.2
При загрузке конфигурации(.cf) в пустую базу и попытке обновить, получал ошибку.
В процессе обновления информационной базы произошла критическая ошибка по причине:
Ошибка при попытке вставки записи с неуникальным значением ссылки.
Microsoft SQL Server Native Client 11.0: Violation of PRIMARY KEY constraint 'PK___Chrc173__AC8ED0C4E093E775'. Cannot insert duplicate key in object 'dbo._Chrc17340NG'. The duplicate key value is (0xa040dc2d4659cfa8487345e49e5c49f4). HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1
В Технологическом журнале зафиксировалась аналогичная ошибка.
«08:52.535000-0,EXCP,4,process=1cv8,Usr=DefUser,dbpid=100,Exception=DataBaseException,Descr="Ошибка при попытке вставки записи с неуникальным значением ссылки. Microsoft SQL Server Native Client 11.0: Violation of PRIMARY KEY constraint 'PK___Chrc173__AC8ED0C4E093E775'. Cannot insert duplicate key in object 'dbo._Chrc17340NG'. The duplicate key value is (0xa040dc2d4659cfa8487345e49e5c49f4). HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1»
Чтобы «расшифровать» имя таблицы воспользовался статьей на nonunique, но без успешно.
Так как при повторной загрузке конфигурации(.cf) получал в ошибке уже другое имя таблицы 'dbo._Chrc552NG', пришлось применить другой метод для поиска причины неуникальной записи. После прочтения статьи
Нашел 3 предопределенных элемента, у которых id одинаковый. После этого перед обновлением конфигурации в конфигураторе, нашел по имени Name объект, удалил и заново создал предопределенный объект, чтобы сгенерить новые id. Конфигурация обновилась.
Причины возникновения ошибки связываю с использованием платформы 8.3.10.2580, в части механизма «Выгрузить конфигурацию в файлы/Загрузить конфигурацию из файлов», т.к. до перехода на 8.3.13.1513, ошибки с обновлением в пустую конфигурацию не было. Как платформа при загрузке конфигурации из файлов смогла обновить и создать элементы с одинаковыми id, останется для меня загадкой и пусть разгадывают в 1С.
В этой статье описан способ решения ошибки "В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка SDBL: Тип поля Code несовместим с типом литерала STRING". Сразу оговорюсь, что описанный метод больше похож на "танцы с бубнами", но, возможно, кому-нибудь сможет помочь или пригодится что-то из того, что я перепробовал. По крайней мере, поможет натолкнуть на правильную мысль, а также будут подняты другие проблемы, интересные к обсуждению.
В процессе обновления нетиповой ИБ выходит ошибка:
Ошибка возникает на этапе обновления конфигурации базы данных.
Начнём с того, что мне посоветовали:
- Выгрузить/загрузить базу
- Выгрузить/загрузить .с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
В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец таблицы ".dbo."; в столбце запрещены значения NULL. Ошибка в INSERT.
Описание ошибки:
Столкнулся с ошибкой при выполнении процедуры Тестирование и исправление. на этапе реструктуризации таблиц информационной базы. База клиент-серверная. 1С: Управление торговлей 10.3.31. Платформа 1С: Предприятие 8.3.9
Сложно сказать, что посчастливилось, но все же ошибка преследовала меня в базе не единожды. Но по своей сути каждая последующая формулировка "В процессе обновления информационной базы произошла критическая ошибка. " отличалсь в причине и решении незначительно. С такой ошибкой столкнулся, если быть откровенным, впервые, но интернет в принятии решения устранения ошибки сильно не помог, кроме вот этого обсуждения на форуме Как удалить строки содержащие NULL в таблице где NULL недопустимо. Зацепок решения не было. Но все же решение было найдено. Читаем. ниже.
Итак, начнем с первого факта возникновения ошибки при выполнении тестирования и исправления базы данных на этапе реструктуризации таблиц базы данных.
Полный текст ошибки:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец "_Fld412", таблицы "Торговля.dbo._Reference19NG"; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
Если взглянуть скрином ранее, то нельзя упустить из виду подсказку, оставленую программой в левом нижнем углу окна программы, в строке состояния, о том, что выполнение реструктуризации прервалось на справочнике "Банковские счета". В базе справочник имел более 3х с половиной тысяч элементов, поэтому сходу было сложно понять, в каком из них скрывается ошибка. Была написана простая обработка, которая просто должны была обойти все элементы справочника и перезаписать их. Надежда была на то, что запись проблемного элемента завершиться ошибкой.
Исполняемый код обработки прост:
Запрос = Новый Запрос ;
Запрос . Текст = "ВЫБРАТЬ
| БанковскиеСчета.Ссылка
|ИЗ
| Справочник.БанковскиеСчета КАК БанковскиеСчета" ;
Выборка = Запрос . Выполнить (). Выбрать ();
Пока Выборка . Следующий () Цикл
СпрОбъект = Выборка . Ссылка . ПолучитьОбъект ();
СпрОбъект . Записать ();
КонецЦикла;
Предположение было оправдано. Ошибка при записи возникла. Теперь было понятно, элемент с каким кодом может быть причиной критической ошибки в процессе обновления информационной базы.
Это оказался элемент справочника, у которого не был заполнен ни одни реквизит, так что мне даже не удавалось пометить такой элемент на удаление. Дальше была написана простая обработка для удаления выбранного элемента справочника без проверки ссылочной целостности. Элемент был удален.
Тестирование и исправление было запущено повторно. Но уже вскоре после запуска процедуры в режиме реструктуризация таблиц базы мен ожидала идентичная ошибка, но уже связанная со справочником "Организации".
Новый текст ошибки отличался лишь немногим, названием таблицы и именем столбца:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец "_Fld888", таблицы "Торговля.dbo._Reference66NG"; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
По опыту предыдущей инцидента уже казалось понятным, что в справочнике у какого-то элемента не заполнены данные. Так и оказалось. Проблемный элемент справочника был найден мгновенно и в этом случае повезло больше элемент можно было пометить на удаление, был помечен и удален с помощью "Удаление помеченных объектов".
Тестирование и исправление было запущено в третий раз. Но и этот раз не обошелся без "критической ошибки в процессе обновления информационной базы".
Текст третьей ошибки:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось вставить значение NULL в столбец "_Fld1024RRef", таблицы "Торговля.dbo._Reference88NG"; в столбце запрещены значения NULL. Ошибка в INSERT.
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=2, Severity=10, native=515, line=1
Но и в этот раз программа оставила подсказку, что проблема содержится в записях справочника "ТипыЦенНоменклатурыКонтрагентов".
Удалить проблемные элементы справочника пришлось программно с помощью все той же, указанной выше простой обработки непосредственного удаления без проверки ссылочной целостности.
И в итоге очередной запуск, уже четвертый по счету, в режиме "Реструктуризация таблиц информационной базы" в рамках тестирования и исправления завершился успешно.
Читайте также: