1с критическая ошибка при обновлении базы данных

В процессе обновления произошла критическая ошибка ☑ 0

falselight

02.07.19

✎

14:02

1

hhhh

02.07.19

✎

14:10

(0) кривые руки?

2

falselight

02.07.19

✎

14:25

(1) Например? Обновления на предыдущие релизы прошло.

И на этот прошло. Но по кнопке, обновить конфигурацию, вот такая ошибка идет

3

falselight

02.07.19

✎

15:11

можно как то устранить эту ошибку, и завершить обновление?

4

falselight

02.07.19

✎

15:14

пробовал обновлять на релиз 11_4_8_82, та же ошибка

5

Garikk

02.07.19

✎

15:22

6

falselight

02.07.19

✎

15:37

(5) Вчера пробовал, прошло.

Потом ещё несколько обновлений сделал.

Но вот на 11_4_8_79, последнем так случилось. Теперь из за этого не продолжить.

И на 11_4_8_82, тоже пробовал. Так же.

7

falselight

02.07.19

✎

15:50

8

Fish

02.07.19

✎

15:52

(7) Взять последний бекап (который перед обновлением), и попробовать снова.

9

ia

02.07.19

✎

15:53

что такое бекап

10

worker-good

02.07.19

✎

15:53

(7) После каждого обновления, заходите в пользовательский режим 1С:Преприятия под админом

11

worker-good

02.07.19

✎

15:54

(9) Бекап, это бек — назад, ап — вверх, в общем улепетываешь со всех ног

12

Fish

02.07.19

✎

15:55

(9) Резервная копия.

13

worker-good

02.07.19

✎

15:56

(12) Значит dt-ник это бекап?

14

Натуральный Йог

02.07.19

✎

15:59

(13) Нет, dt-шник это не копия бд

15

Натуральный Йог

02.07.19

✎

15:59

dt-шник это выгрузка

16

falselight

02.07.19

✎

16:16

17

falselight

02.07.19

✎

16:18

(15) Я начал обновление УТ на 10 релизов, после каждого обновления запускаю 1с предприятие, и про доделываю успешно обработки обновления дополнительные.

18

Натуральный Йог

02.07.19

✎

16:24

(17) Держи меня в курсе

19

falselight

02.07.19

✎

16:26

20

Fish

02.07.19

✎

16:27

(13) Нет.

21

Натуральный Йог

02.07.19

✎

16:27

(19) Серверная?

22

falselight

02.07.19

✎

16:28

(8) Я обновил на 9 релизов, какой бэеап?

(21) Да серверная

23

sqr4

02.07.19

✎

16:28

Однажды я сделал копию ДТ, затем протестировал базу и ей пришла хана, а потом ДТшник не загрузился.

С тех пор я делаю ДТ только для перемещения между файловой и серверной базой

24

falselight

02.07.19

✎

16:29

(23) Мне бы понять как в моем случае быть.

А то одни, процессы, процессы, и ошибка!!! Или ошибки!

25

Натуральный Йог

02.07.19

✎

16:30

(22) Перегони в файловую и попробуй

26

hhhh

02.07.19

✎

16:32

27

falselight

02.07.19

✎

16:55

режим совместимости стоит 8.3.12

может тут что поменять? А то при ТиИ ругалось что то на режим совместимости.

28

hhhh

02.07.19

✎

17:04

(27) а запускаешь на 14й? или уже на 15й?

29

falselight

02.07.19

✎

17:42

(28) 8.3.13.1644

30

hhhh

02.07.19

✎

17:44

(29) ну работай на 12й пока. не надо на 13ю

31

falselight

02.07.19

✎

18:19

(30) В смысле что нужно 15 ставить?

32

falselight

02.07.19

✎

18:23

(30) Там 13я стоит (29), от куда 12 ая? И этому обновлению ут не нужно ничего такого!

33

Роман

02.07.19

✎

19:58

postgresql? Решилось накатыванием этого обновления в файловом варианте.

34

Fram

02.07.19

✎

22:04

(33) вот ты спросил! если б он знал, неужели, не упомянул бы в (0) об этом?!

(22) +100500. С бэкапом оно каждый может. А вы без рискните.

35

hhhh

02.07.19

✎

22:12

(34) это же мелочевка, всего-то 9 обновлений, нахрена еще какой-то «бэеап» ?

36

falselight

03.07.19

✎

05:14

Тестирование и исправление завершилось.

37

falselight

03.07.19

✎

05:15

Но ошибка (0) повторяется.

38

Мимохожий Однако

03.07.19

✎

06:27

(37) Вернись на предыдущий релиз из архива, который есть и начинай заново. Но можно начать новую ветку на форуме,если не понял.

39

Роман

03.07.19

✎

07:37

Еще раз повторюсь. База легко проходит обновление в файловом режиме. Это проблема не данной базы, а что-то системное.

С данной проблемой уже столкнулся у двух разных клиентов. Платформы разные 8.3.12.1685 и 8.3.13.1644. Объединяет их только использование postgresql. На Ms SQL не пробовал.

40

Turku

03.07.19

✎

07:42

Да, обновление кривое, видимо. Даже на демо-базе такую же ошибку выдает. Да, на Postgre. В файловом варианте все норм. На боевую базу его решил не ставить. Кстати, уже есть 11.4.8.82.

41

Роман

03.07.19

✎

11:39

При обновлении на 11.4.8.82 минуя 11.4.8.79 та-же проблема.

42

falselight

03.07.19

✎

12:51

(38) Так и хотели сделать. И остановиться на 11_4_7_150

Но сейчас какие то ошибки пошли и в старой версии базы данных.

Там postgre sql.

43

falselight

03.07.19

✎

12:52

(39) Обновление проходит, но потом её не загрузить в postgre sql. Снова ошибки.

44

falselight

03.07.19

✎

12:54

(40)(41) Да, на релизе 11.4.8.82, та же ошибка.

45

falselight

03.07.19

✎

12:54

(41) Точно!

46

Роман

03.07.19

✎

19:12

Странно. У меня без проблем загрузилось обратно.

47

Фрэнки

03.07.19

✎

19:21

может, как это бывает, проблема в разрядности платформы? и там, где используют 64 битную, то у всех все нормально и не жалуются на такую ошибку?

48

Мимохожий Однако

03.07.19

✎

21:16

(45) Тогда не пропускай релизы

49

WhiskeyInThe Jar

04.07.19

✎

15:36

Пробовал обновлять на SQL тоже выскакивает ошибка

«Ошибка при получении значения из базы данных. Возможной причиной является отсутствие установленного Microsoft SQL Server Native Client.»

В итоге методом исключения нашел что не нужно обновлять справочник «НаборыДополнительныхРеквизитовИСведений», там косяк при изменение имен предопределенных элементов.

Без его изменений обновление ставится.

50

diktator

05.07.19

✎

10:08

51

diktator

05.07.19

✎

15:38

52

diktator

07.07.19

✎

10:13

Update:

Ответ от техподдержки 1С: прислать лог технологического журнала rphostXXX.log. Повторяем обновление, высылаем лог, ждем ответа.

53

craxx

07.07.19

✎

10:14

(50) платформу надо бы обновить. 8.3.12.1685 редкостно глючная

54

diktator

11.07.19

✎

08:52

Пришел ответ от 1С:

Обновить платформу до 8.3.15 и postgre до 10.

Будем осуществлять на тестовом сервере.

55

Фрэнки

11.07.19

✎

08:59

(53) Я стараюсь из такой ветки только 8.3.12.1790 использовать. Но в продуктиве у меня ее уже нет.

Продуктив сейчас на 8.3.14.1779

А в тестовую машину уже поставил 8.3.15.1489

56

diktator

11.07.19

✎

13:47

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

20 июня, 2019
20 июня, 2019

Дано

При применении конфигурации в РИБ возникает критическая ошибка и конфигуратор аварийно завершается.
Затем, при попытке зайти в конфигуратор, 1С выдает следующее сообщение: “При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?”
Выбор любого из действий ни к чему не приводит и если ответить утвердительно, то повтор обновления не происходит.
Попытка вернуться к конфигурации БД через параметр командной строки /RollbackCfg так же не увенчалась успехом. При использовании этого метода в диспетчере задач видно, что 1С запускается на 2-3 секунды и даже не успевает развернуться в памяти, и фактически не отрабатывает.

Версия платформы 8.3.13.1809 (клиент-сервер)

Решение

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

Итак суть решения состоит в том чтобы очистить некоторые данные в таблицах БД (SQL), которые говорят системе о незавершенном обновлении. Нужно выполнить запросы к БД.
Конечно же я настоятельно рекомендую выполнять все действия при наличии резервной копии БД, причем средствами сервера БД. Но если на это нет времени, то мы себя немного обезопасим резервной копией таблиц.

select * into Config_tmp from Config
select * into ConfigSave_tmp from ConfigSave

delete from ConfigSave

delete from config where FileName = 'commit'
delete from config where FileName = 'dynamicCommit'
delete from config where FileName = 'dbStruFinal'

Кстати о возможности возврата к отправной точке, первые два select копируют две таблицы, с которыми мы будем выполнять действия и создают временные таблицы Config_tmp и ConfigSave_tmp на всякий случай для возможности возврата.

первый из delete удаляет все данные таблицы ConfigSave.
остальные удаляют определенные записи из таблицы config.

После выполнения этих действий вы сможете зайти в 1С в режиме конфигуратора, при этом все ваши изменения будут потеряны.

Если все прошло удачно, то нужно удалить временные таблицы которые мы создавали.

drop table Config_tmp
drop table ConfigSave_tmp

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

Предыстория

Нужно нам было создать новый регистр сведений «ЖурналОтслеживанияСообщений». Добавили в конфигурацию, загрузили данные. Затем пошла работа по оптимизации. Пришлось менять структуру регистра. Но не тут-то было!

Тут все ясно. Записи стали неуникальными, нужно их удалить!

Самой простой способ это:

НоваяЗапись = РегистрыСведений.ЖурналОтслеживанияСообщений.СоздатьНаборЗаписей();
НоваяЗапись.Записать();

Таким методом мы очистим регистр в 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,d7, , Sep 27 4015 10:22PM, 768404,00,00,00,00,00,00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

Пояснение

Давайте разберемся со структурой SQL. У нас есть регистр «ЖурналОтслеживанияСообщений», он в SQL находится в таблице «_InfoR34546″. Проверить это вы можете специальными обработками или методом «тыка» (нам это не придется делать т.к. в тексте ошибки уже указано название таблицы).

А теперь поясню, что же произошло. Когда мы загрузили данные в регистр, то в SQL они попали в таблицу »
_InfoR34546″. Когда мы кодом в 1С очистили таблицу, то эти данные удалились из таблицы »
_InfoR34546″, но они скопировались в таблицу «_InfoRgChngR34546″. Это и стало проблемой.

Решение

Для решения возникшей проблемы нам понадобится очистить SQL
таблицу »
_InfoRgChngR34546″.

Расскажу на примере «Microsoft SQL Server Management Studio». Заходим в «Management Studio». Находим нашу базу, открываем вкладку таблиц, кликаем на любую и жмем кнопку «Новый запрос»:. Теперь набираем запрос

Truncate table «_InfoRgChngR34546
»

У вас может быть и другая таблица! Не забывайте!

И жмем выполнить или клавишу «F5». Вот такой должен быть результат:

Все, теперь можно спокойно обновлять 1С, и ошибки не будет!

Песочница

авторитет

18 сентября 2013 в 15:24

1С, восстановление конфигурации информационной базы с использованием MS SQL

В свое время столкнулся с проблемой: при обновлении конфигурации из хранилища, произошел сбой, и закрылась 1С.

Как выяснилось позднее – произошло разрушение хранилища конфигурации и при обновлении конфигурации из хранилища слетела и конфигурация БД. Подобная ошибка возникала прежде при динамическом обновлении ИБ.

Т.к. данная проблема возникала не однократно решил поделится вариантом лечения.

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

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

Вариант 1 (при наличии бэкапа SQL c копией с идентичной конфигурацией):

Разворачивается копия ИБ, и выполняется запрос следующей конструкции:
USE
GO
DELETE FROM ..
GO
INSERT INTO .. SELECT * FROM ..
GO

При этом пере заливается таблица в которой хранится конфигурация ИБ. Желательно после данной операции выполнить тестирование и исправление ИБ.

Вариант 2 (при отсутствии бэкапа):

К данному варианту обратились как к последней соломинке. Т.к. конфигурация была в стадии разработки и про бэкап немного позабыли понадеясь на хранилище.
В базе удаляются две записи из таблицы «Config» по значению в столбце «FileName» — dbStruFinal и commit

Выполняется следующий запрос:
USE
GO
DELETE FROM .
WHERE FileName = «dbStruFinal»
GO
DELETE FROM .
WHERE FileName = «commit»
GO

Как ни странно база оживает.

Теги:
1с предприятие 8.2, SQL, восстановление конфигурации

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

При работе в «1С:Предприятие» может всплыть следующее сообщение: «Для работы с новой версией 1С:Предприятия должно быть выполнено преобразование информационной базы». Почему появляется это окно и как можно устранить ошибку?

В большинстве случаев причина появления окна – недавний переход программы с устаревшей версии платформы на более новую. У разных платформ информационная база 1С
формируется по-своему и принимает разный состав. Всё, что требуется сделать – произвести конвертацию базы данных (структура которой соответствует устаревшей платформе) в самый новый формат.

Преобразование БД

Процедура эта несложная, однако, сначала рекомендуется создать резервную копию базы, на случай, если во время конвертирования произойдёт ошибка (например, отключится компьютер, в результате информационная база 1С
, как и сама программа, могут повредиться). Затем примените следующий алгоритм действий:

• Откройте БД в режиме конфигуратора;
• Вы увидите сообщение с предложением конвертировать информационную базу. Нажмите подтверждение;

• Закройте конфигуратор.

Откройте базу данных – она должна запуститься без проблем. Если после преобразования окно с ошибкой продолжает появляться, можно попробовать выполнить процедуру повторно. В случае, когда и это не помогает, необходимо обратиться к программисту 1С. Иногда при выполнении операции программа может подвисать. Не надо в этот момент предпринимать никаких действий.

Важно! Информационная база 1С
, преобразованная последней версией программы, не может быть открыта на предыдущих версиях.

Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.

Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:

«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

После нажатия кнопки «Да» появляется следующее:

«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.

На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.

Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:

Решение:

1. То, чего не хватало для решений из сети:

sp_configure ‘allow updates’, 1
reconfigure with override
go

2. Переводим базу в режим восстановления

alter database set EMERGENCY, SINGLE_USER

3. Выполняем тестирование базы:

dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS)

4. Выводим базу из режима восстановления:

alter database set ONLINE, MULTI_USER

5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:

delete from config where FileName = ‘commit’

delete from config where FileName = ‘ dbStruFinal’

Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.

В рабочих версиях баз запросы:

select * from Config WHERE FileName = ‘commit’

select * from Config WHERE FileName = ‘dbStruFinal’

будут пустые.

6. возвращаем настройки:

sp_configure ‘allow updates’, 0
go

7. После этого удалось запустить конфигуратор и база заработала.

Также база может заработать после удаления первого флага.

В процессе обновления произошла критическая ошибка

Автор NataliaGon, 26 июн 2018, 15:45

0 Пользователей и 1 гость просматривают эту тему.

---

---

---

---

---

---

---

---

---

---

Добрый день!

Занимаюсь разработкой конфигураций на основе платформы 1С: Предприятие. При разворачивании копии базы сформированной средствами 1С: Предприятие регулярно появлялась ошибка:

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем «dbo._AccRg2024NG» и индекса с именем «_AccRg2024_ByPeriod_TRNNG». Повторяющееся значение ключа: (сен 30 4013 12:00AM, 0x0000001c, 0x83fd001b78e2ed3011e342e2cb8d7e1c, 1).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

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

Выяснение имени таблицы 1С связанной с объектом определяется функцией ПолучитьСтруктуруХраненияБазыДанных, там же можно поглядеть и состав индексов.

Как оказалось данные индексы в таблице SQL «_AccRg2024» отсутствовали физически. При дальнейшем анализе данных уже средствами SQL выяснилось, что не уникальными были номера записей в разрезе Периода — [_Period], регистратора — [_RecorderRRef] и номер записи [_LineNo], из за чего и не происходила реструктуризация таблицы. Кто и как умудрился удалить эти индексы история умалчивает, данный факт восстановлению не подлежит.

Вылечилась данная ситуация следующим запросом:

USE [DB]
GO

CREATE TABLE #TempRecorder (_RecorderRRef BINARY(16))
GO

INSERT INTO #TempRecorder 
	SELECT T.[_RecorderRRef]
	FROM (SELECT COUNT(*) as _count , T1.[_Period]  ,T1.[_RecorderRRef] ,T1.[_LineNo]      
			FROM [dbo].[_AccRg2024] AS T1	 
			GROUP BY T1.[_Period] ,T1.[_RecorderRRef]  ,T1.[_LineNo]
			HAVING count(*) > 1 ) AS T
	
	--WHERE T.[_RecorderRRef] = 0xBA80000C29053BCD11E2FF4303EA5AA7

	GROUP BY T.[_RecorderRRef]

DECLARE @_Count numeric(10), @_Period datetime, @_RecorderRRef binary(16), @_LineNo numeric(9,0);

DECLARE @i int;
SET @i = 0;

DECLARE _Recorder_Cursor CURSOR FOR
SELECT * FROM #TempRecorder;

OPEN _Recorder_Cursor
FETCH NEXT FROM _Recorder_Cursor INTO @_RecorderRRef;

WHILE @@FETCH_STATUS = 0
   
	BEGIN
		DECLARE _Cursor CURSOR FOR
		SELECT [_Period], [_LineNo] FROM [dbo].[_AccRg2024]
		WHERE [_RecorderRRef] = @_RecorderRRef

		OPEN _Cursor

		SET @i=0;

		FETCH NEXT FROM _Cursor INTO @_Period, @_LineNo

		WHILE @@FETCH_STATUS = 0

			BEGIN
				SET @i = @i + 1 

				UPDATE [dbo].[_AccRg2024] SET [_LineNo] = @i
				WHERE CURRENT OF _Cursor

				FETCH NEXT FROM _Cursor INTO @_Period, @_LineNo

			END;

		CLOSE _Cursor;
		DEALLOCATE _Cursor;

	FETCH NEXT FROM _Recorder_Cursor INTO @_RecorderRRef;
	
	END

CLOSE _Recorder_Cursor;
DEALLOCATE _Recorder_Cursor;

GO

DROP TABLE #TempRecorder
GO

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

После этого, уже средствами 1С, выполнилось тестирование базы с режимом «Реструктуризация таблиц информационной базы», данная процедура пересоздала индексы в таблице, и дальнейшие манипуляции, при работе с метаданными конфигурации, стали происходить без каких либо ошибок.