Добрый день!

Обнаружилась следующая проблема, при обновлении конфигурации БухгалтерияПредприятия с версии 3.0.82.24 до 3.0.85.28. Сама конфигурация встает успешно, однако после запуска 1С, требуется выполнить переход на новую версию. И вот здесь встречается проблема: при достижении 93% обновление намертво замирает, оставляли на ночь - никаких изменений. Зависает конкретно всегда в одной процедуре "РегистрыСведений.СтатусыДокументов.ЗаполнитьНомераСчетовФактурПоДокументамРеализация", а именно при выполнении самого первого запроса в процедуре:

"ВЫБРАТЬ ПЕРВЫЕ 1000
    |    РеализацияТоваровУслуг.Организация КАК Организация,
    |    РеализацияТоваровУслуг.Ссылка КАК Документ,
    |    ЕСТЬNULL(СтатусыДокументов.Статус, &СтатусПоУмолчанию) КАК Статус,
    |    ЕСТЬNULL(СтатусыДокументов.ДополнительныйСтатус, &ДополнительныйСтатусПоУмолчанию) КАК ДополнительныйСтатус,
    |    ЕСТЬNULL(СтатусыДокументов.СтатусСчетаФактуры, &СтатусСчетаФактурыПоУмолчанию) КАК СтатусСчетаФактуры,
    |    ЕСТЬNULL(СчетФактураВыданныйДокументыОснования.Ссылка.ПредставлениеНомера, """") КАК НомерСчетаФактуры
    |ИЗ
    |    Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
    |        ЛЕВОЕ СОЕДИНЕНИЕ Документ.СчетФактураВыданный.ДокументыОснования КАК СчетФактураВыданныйДокументыОснования
    |        ПО РеализацияТоваровУслуг.Ссылка = СчетФактураВыданныйДокументыОснования.ДокументОснование
    |            И (НЕ СчетФактураВыданныйДокументыОснования.Ссылка.ПометкаУдаления)
    |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтатусыДокументов КАК СтатусыДокументов
    |        ПО РеализацияТоваровУслуг.Ссылка = СтатусыДокументов.Документ
    |ГДЕ
    |    НЕ СчетФактураВыданныйДокументыОснования.Ссылка ЕСТЬ NULL
    |    И НЕ СтатусыДокументов.Документ ЕСТЬ NULL
    |    И СтатусыДокументов.НомерСчетаФактуры = """"
    |    И СчетФактураВыданныйДокументыОснования.Ссылка.ПредставлениеНомера <> """"
    |
    |УПОРЯДОЧИТЬ ПО
    |    РеализацияТоваровУслуг.Дата УБЫВ";


В чем может быть проблема?

попробуй может на другой платформе ?
если не помогло- разбирайся, что там в регистре и чем заполняется, возможно где -то косяк, может через попытку пустить и т п

(1) Пробовали и на более старой платформе (8.3.16) и на самой новой. У нас 3 базы, одна база успешно обновилась без каких-либо проблем (впрочем, с ней никогда проблем при обновлении не случалось), а две другие базы попались на эту ошибку

(2) там наверно по шагам надо делать обновление. Нельзя сразу прыгать с 82 на 85. Попробуйте для начала на 83.

(3) =)
3.0.84.35     05.11.20         3.0.82.24 последняя)

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

Явно же, что проблема в наличии каких-то данных... Собственно, запрос потому и виснет, когда он не пустой.

И интересно, что реально хотели перепрыгнуть сразу в 8.0.85 без промежуточного обновления?

обновляемые версии 3.0.83.33, 3.0.83.37, 3.0.84.31, 3.0.84.35, 3.0.84.42, 3.0.84.46, 3.0.85.25
где вы взяли 82-ю?

(4) (5) (6) Да, я ошибся. 3.0.85.28 была целевой версией, обновлялись через промежуточную 3.0.84.35. К слову, данная процедура "РегистрыСведений.СтатусыДокументов.ЗаполнитьНомераСчетовФактурПоДокументамРеализация" добавляется в рамках этого обновления

Пробовал так же выгрузить конфигурацию с той базы, в которой обновление прошло успешно, и загрузить в ошибочную - результат такой же

исправь 1000 на 100 в запросе

(8) ты серьезно думал, что манипуляция с готовым ЦФ могла помочь?

А ты уверен, что запрос именно зависает, а не выполняется в цикле? У меня такое было когда длину номера документа меняли в конфиге и процедуры обновления не могли нормально его записать.

уверен, там регистр СтатусыДокументов запоролся, с ним часто такое бывает после всяких обменов

(10) Конфигурации этих трех баз должны быть одинаковыми, однако давным давно что-то пошло не так
(9) (11) Исправил в запросе на 100, теперь видно, что запрос выполняется, однако скорость работы... 100 документов данный метод обрабатывает примерно минут 5 (пока запущен в отладчике, наверняка без него будет быстрее, но не в десятки же раз?)
С чем может быть связана такая скорость работы? В успешно обновленной базе конечно меньше документов, но не в сотни раз, а так данное обновление поставилось вообще без каких-либо проблем

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

Кстати, получить готовый cf на первой обновляемой базе и затем использовать его для обновления остальных - подход правильный в целях экономии времени на восстановление "конфигурации поставщика" из cf, но эта манипуляция ничего не изменит в выполнении именно обработчиков данных, которые запускаются уже при первом запуске в режиме Предприятие

Разница в скорости выполнения обновления в разных базах зависит вероятно только от количества документов. Вероятно, что в каких-то базах или просто нет выдачи счет-фактур или время жизни баз очень сильно отличается.

А база файловая или sql ? Не постгрес, случаем? Он любит задуматься, когда соединение с подзапросом. Костыль enable_nestloop=off помогает.

обновляй на 8.3.16.последней, та же проблема была, все обновилось

..на файловой

(16) база файловая
(18) сейчас пробовал обновлять на 8.3.18, попробую на 8.3.16

(19) не поможет

Фоновые задания включены ?

(20) как не странно, но обновиться на более старой версии платформе получилось (100 записей обрабатывались за 1-3 секунды)
(17) большое спасибо!

(17) спасибо, меня тоже от гемора спасло, типовая ЗП тоже полетела, пришлось откатиться.

8.3.15 - дт - 8.3.18, а потом обновления с 3кв и никаких проблем