Здравствуйте. При обновлении конфигурации Бухгалтерия Предприятия (файловая) с версии 3.0.58.41 на 3.0.59.43(45) на конечном этапе доходит до 94%, долго висит и обновление заканчивается с ошибкой. Теперь при каждом запуске базы пишет "Не завершен переход на новую версию", при нажатии на это уведомление показывает, что ошибка произошла на:
Повторный запуск невыполненных процедур не помогает. Запуск отложенного обновления ИБ в регламентных заданиях тоже не спасает.
Подскажите пожалуйста, как это исправить?
Процедура "УчетСтажаПФР.ВосстановитьОтсутствующиеИнтервалыВторичногоРегистра" обработки данных завершилась с ошибкой:
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(4249)}: Превышено допустимое количество запусков процедуры обновления.
Выполнение прервано для предотвращения зацикливания механизма обработки данных.
ВызватьИсключение ТекстОшибки;Повторный запуск невыполненных процедур не помогает. Запуск отложенного обновления ИБ в регламентных заданиях тоже не спасает.
Подскажите пожалуйста, как это исправить?
Прикрепленные файлы:
По теме из базы знаний
- Не завершен переход на новую версию 11.2
- Групповое удаление помеченных на удаление документов без контроля ссылочной целостности для УТ 10.3
- Учет УНФ в НДС: убираем НДС из прибыли в 1С:УНФ
- Подключение функционала БСП "Присоединенные файлы" к функционалу Диадок
- Интеграция 1С с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода - для УНФ, УТ, КА, ERP
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2)
Это?
Смотрите процедуру обработчика
Это?
Процедура ВосстановитьОтсутствующиеИнтервалыВторичногоРегистра(ПараметрыОбновления = Неопределено) Экспорт
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| ПериодыСтажаПФР.ФизическоеЛицо КАК ФизическоеЛицо,
| ДАТАВРЕМЯ(1, 1, 1) КАК Начало,
| ДАТАВРЕМЯ(1, 1, 1) КАК Окончание
|ПОМЕСТИТЬ ВТКлючиИзменившихсяДанных
|ИЗ
| РегистрСведений.ПараметрыПериодовСтажаПФР КАК ПериодыСтажаПФР
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПериодыСтажаПФР КАК ПериодыСтажаПФРПересекающие
| ПО ПериодыСтажаПФР.ГоловнаяОрганизация = ПериодыСтажаПФРПересекающие.ГоловнаяОрганизация
| И ПериодыСтажаПФР.ФизическоеЛицо = ПериодыСтажаПФРПересекающие.ФизическоеЛицо
| И ПериодыСтажаПФР.ТипДоговора = ПериодыСтажаПФРПересекающие.ТипДоговора
| И ПериодыСтажаПФР.Начало >= ПериодыСтажаПФРПересекающие.Начало
| И (ПериодыСтажаПФР.Начало <= ВЫБОР
| КОГДА ПериодыСтажаПФРПересекающие.Окончание = ДАТАВРЕМЯ(1, 1, 1)
| ТОГДА &МаксимальнаяДата
| ИНАЧЕ ПериодыСтажаПФРПересекающие.Окончание
| КОНЕЦ)
|ГДЕ
| ПериодыСтажаПФРПересекающие.Начало ЕСТЬ NULL
| И (ПериодыСтажаПФР.ТипДоговора = &ГражданскоПравовой
| ИЛИ НЕ ПериодыСтажаПФР.ВнутреннееСовместительство)
| И ПериодыСтажаПФР.ВидСтажаПФР <> &НеВключаетсяВСтраховойСтаж
|;
|
|//////////////////////////////////////////////////////////// ПоказатьПрикрепленные файлы:
На Форуме описана эта ошибка.
С 3.0.58.41 на 3.0.59.43
---------------
Обновить демобазу или копию резервной копии до обновления, выгурузить оттуда файл конфигурации CF и накатить замещением
Я сейчас попробовал - обновил без проблем из конфигуратора на 1C 8.3.10.2667 (64-битной) с 3.0.59.43 на 3.0.59.45
--------------
Проверено лично: с релиза 3.0.58.41 через cf релиза 3.0.59.45 обновление прошло успешно.
С 3.0.58.41 на 3.0.59.43
---------------
Обновить демобазу или копию резервной копии до обновления, выгурузить оттуда файл конфигурации CF и накатить замещением
Я сейчас попробовал - обновил без проблем из конфигуратора на 1C 8.3.10.2667 (64-битной) с 3.0.59.43 на 3.0.59.45
--------------
Проверено лично: с релиза 3.0.58.41 через cf релиза 3.0.59.45 обновление прошло успешно.
(9) Это я же там вопрос задал ))
На уже обновленной до 3.0.59.45 не прокатило к сожалению. Скорее всего получилось бы на 3.0.58.41, которая до обновления, но уже много работы сделано в базе после обновления, поэтому даже пробовать не буду.
Теперь только надежда, что всё исправится со следующим обновлением.
На уже обновленной до 3.0.59.45 не прокатило к сожалению. Скорее всего получилось бы на 3.0.58.41, которая до обновления, но уже много работы сделано в базе после обновления, поэтому даже пробовать не буду.
Теперь только надежда, что всё исправится со следующим обновлением.
(9) Замечу, что меня сбила с толку Ваша фраза: "обновил без проблем из конфигуратора"
Из конфигуратора у меня проблемы с обновлением и не было. Т.е. сама конфигурация обновлялась как положено. Но вот дальше, при открытии базы в пользовательском режиме, обработчик данных зацикливался.
Если Вы подразумевали это в своём сообщении, то вопросов нет.
Из конфигуратора у меня проблемы с обновлением и не было. Т.е. сама конфигурация обновлялась как положено. Но вот дальше, при открытии базы в пользовательском режиме, обработчик данных зацикливался.
Если Вы подразумевали это в своём сообщении, то вопросов нет.
Попробовала "Обновить демобазу или копию резервной копии до обновления, выгурузить оттуда файл конфигурации CF и накатить замещением" с релиза 58.41. Все равно не получилось.
У меня тоже часть баз обновилась без проблем, а одна зависла. Ничего сделать не могу. Только не знаю, решит ли новый релиз эту проблему, т.к. у меня возникла проблема при обновлении 58.41 на 59.43 ранее. думала, что следующий релиз исправит. Но с 59.43 на 59.45 опять ошибка.
Если вы сможете как нибудь решить, то напишите пожалуйста.
У меня тоже часть баз обновилась без проблем, а одна зависла. Ничего сделать не могу. Только не знаю, решит ли новый релиз эту проблему, т.к. у меня возникла проблема при обновлении 58.41 на 59.43 ранее. думала, что следующий релиз исправит. Но с 59.43 на 59.45 опять ошибка.
Если вы сможете как нибудь решить, то напишите пожалуйста.
Добрый день!
Вдруг поможет... Я копался в отладчике, и в моём случае решение оказалось довольно простым в конечном итоге. Оказывается два сотрудника в БД были УВОЛЕНЫ, но не были ПРИНЯТЫ на работу. Т.е. ссылки на кадровые документы в карточке сотрудника не было, была только ссылка "Принять на работу". Принял я их на работу задним числом и обновление прошло без проблем. Речь о версии 59.43. Как только я провел документы о принятии на работу, то смог, не закрывая базу повторно запустить оставшиеся процедуры обновления и всё стало на свои места. Вслед за этим переход на 59.45 прошёл "без задоринки".
А конкретно проблема заключалась в том, что запрос возвращал некорректные даты по регистру ПериодыСтажаПФР, точнее, дата была дефолтной, т.е. строки запроса
Давали 01.01.0001.
Всех благ!
Вдруг поможет... Я копался в отладчике, и в моём случае решение оказалось довольно простым в конечном итоге. Оказывается два сотрудника в БД были УВОЛЕНЫ, но не были ПРИНЯТЫ на работу. Т.е. ссылки на кадровые документы в карточке сотрудника не было, была только ссылка "Принять на работу". Принял я их на работу задним числом и обновление прошло без проблем. Речь о версии 59.43. Как только я провел документы о принятии на работу, то смог, не закрывая базу повторно запустить оставшиеся процедуры обновления и всё стало на свои места. Вслед за этим переход на 59.45 прошёл "без задоринки".
А конкретно проблема заключалась в том, что запрос возвращал некорректные даты по регистру ПериодыСтажаПФР, точнее, дата была дефолтной, т.е. строки запроса
| ДАТАВРЕМЯ(1, 1, 1) КАК Начало,
| ДАТАВРЕМЯ(1, 1, 1) КАК Окончание
Давали 01.01.0001.
Всех благ!
а где в карточке вы это смотрели? У меня тоже есть уволенные сотрудники в январе (как раз между релизами). Открыла карточки их в самой БД - предприятие, но там у меня и приказ о приеме и об увольнении все есть.
Опишите подробнее пожалуйста, тоже хочу проверить.
Опишите подробнее пожалуйста, тоже хочу проверить.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот