УПП для КЗ на 8.1

Обнаружилась такая вот фигня.
В некоторых (слабо систематизируемых) случаях документы делают двойные движения по некоторым регистрам, при этом первая половина движений в измерениях типа документ имеет <объект не найден> (там, где должен быть записан документ-автор, это НЕ регистратор, фиг знает, для чего это...). При перепроведении эти некорректные движения пропадают.
Ситуация сложно воспроизводимая, случается только при первом проведении и не всегда, даже если копировать проблемный документ.

Выявленные закономерности:

Регистр Закупки, документ Авансовый отчет с тч Прочее.

Регистры ДенежныеСредства, СписаниеДенежныхСредств, документы ППИ с тч Услуги.


Кто-нибудь сталкивался? Причины?
Копаю проведение, подозреваю процедуру записи движений через сотню копирований таблиц движений и с ЗаполнитьЗначения() - сталкивалась уже с корявостью это функции в отношении набора движений...

ТИИ

(0) >документ имеет <объект не найден>
ну явно ж к доктору. если, конечно, там где-то внутри не генерятся непонятные левые ссылки

Исправляет, но не лечит

(3)
Лишь чашка сакэ способна исправить
Две тысячи миль расстоянья.
Исправить, но не исцелить.

Чешское сакэ льется в рот,
Ласкает чувства, но не просветляет разум,
Ждет ответа на рассвете взволнованный юзер...

Похожее было, с задвоением/затроением движений (рекорд, вроде, зашестерение)+иногда с некорректной ссылкой на регистратор -  в период с большим количеством проблем с производительностью и дедлоками(откатами, соотв., жертв-транзакций и пр). Оперативно исправляли поиском, перепроведением, удалением "фантомных" движений (с некорректным регистратором). Исчезло полностью после устранения проблем с блокировками.

Помой свой рот,
Отринь все беды,
Пойдём искать рассвет

(6) тфу на тебя ;)

ну извините ;p

Рассвет после кромешной тьмы...
Мигает последняя звезда...
Да муж почему-то против :(

(6)В смысле, управляемые блокировки?

Как много общего у них
С моей женой...
Внимательно пост №6 читала?

Кстати, регистратор садится корректно во все движения, "кривой" реквизит в таблицу для записи устанавливается везде одинаково:
ЗаполнитьЗначения(Ссылка,"ДокументЗакупки")

(11) В основном, да. Переписал конфу на них.
Это не значит, что у тебя то же самое. Я отвечал на вопрос "Сталкивался ли кто-то с подобным". Postgre, не мощный сервер и относительно много пользователей (до 200).

(12)Проблема похожая, одно но
Порой воспроизводится проблема
в локальной файловой базе
с одним активным пользователем.

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

(14)Пользователей на пике около 50, оборудование хорошее.
Я почему на код грешу.
Была ситуация, если кто разбирал проведение списания по партиям БУХ, общий модуль УправлениеЗапасамиПартионныйУчет, процедура СписаниеНаСчетБух (если не путаю ничего на память), там были добавлены движения, которые заполнялись именно через ЗаполнитьЗначения и в таблице все выглядело красиво, а вот при записи движений преобразовывалось в какие-то безумные значения субконто, которых и у счета-то нет... Исправилось после тупого поименного копирования реквизитов.

(16)Вот закономерность устойчивого воспроизведения не могу поймать, но возникают такие документы регулярно - 2-3 документа в месяц, учитывая, что я не знаю, сколько раз остальные доки перепроводили. Повторю: проблема возникает исключительно при первичном проведении.

это хорошо известный баг 8.1 при транзакционных блокировках и ранее в ут 10.3 с таким сталкивался.

печально

фото понравилось :-)

(21) Не, для таких тем только ню подходит))

(22)Не надо. Ню это для "У меня тут запрос в цикле тормозит что-то", а я так, просто был свободный вечер :)

Могло из-за следующего

Документ не записан, его хотят провести

Генерится новая ссылка

Создаются движения в наборе записей Движения.БлаБлаБла

Возникает ошибка и документ не записывается, но движения с уже битой ссылкой остаются в наборе

Его проводят еще раз, и новые движения добавляются к старым с битой ссылкой

Лечится очисткой всех наборов движений перед записью с режимом проведения (если не обмен)

А лучше - перед любой записью если не обмен

[url=http://narod.ru/disk/43538367001.ff276123f192586c9e766da87eca10d7/ОчисткаИнформационнойБазыОтДанныхПоСпискуОрганизаций.epf.html]ОчисткаИнформационнойБазыОтДанныхПоСпискуОрганизаций.epf[/url]

Фу блин. Щас...

http://narod.ru/disk/43538367001.ff276123f192586c9e766da87eca10d7/ОчисткаИнформационнойБазыОтДанныхПоСпискуОрганизаций.epf.html

Там еще регистры сведений прилагались, но там видно какая структура должна быть

Чорт! Не та тема

(0)Обмен УРБД есть?

(31)Обмена нет

(24)Да похоже на то и похоже действительно проблема с блокировками. Сегодня шерстила журнал регистрации, картина более менее ясна. Возникает, когда новый документ проводят по ОК (т.е. запись и проведение в одном флаконе), в ЖР картина следующая:
20:56 Запись об отмене регистрации объектов доступа
20:04 Зафиксировано Добавление документа
20:04 Зафиксировано проведение документа

в документе
20:56 проводки с битыми ссылками в реквизитах Документ
20:04 нормальные проводки.

Почему-то при откате из-за блокировки чистит не все движения (например, бух. регистры чисты, те же Расчеты с контрагентами нормальны, а взаиморасчеты с контрагентами двоят).

Буду копать.

(0) древний баг платформы вроде...

(32) Может у юзера, который проводит документы нет прав на те документы, что в ссылки должны попасть?

(34)Туда садится этот же самый документ :)

(32)
Откатываются только данные, которые сохранены в базе. А наборы записей это переменные, которые висят в воздухе. Они при ошибках не откатываются

(36)Тогда почему выборочно? И только одни и те же регистры на разных документах с разным набором движений?

(37)
Потому что при проведении одних ошибка (например по блокировке) возникает, а при проведении других - нет и они сразу проводятся

Поэтому у одних в наборе записи от двух попыток провестись, а у других - от одной

Процедура ПередЗаписью()
   Если не обмен Тогда
       Для каждого Набор из Движения Цикл
           Набор.Очистить();
       КонецЦикла;
   КонецЕсли;
КонецПроцедуры


Как-то так надо

(40)ПередЗаписью? А потом у меня при каждом Записать(РежимЗаписиДокумента.Запись) будут удаляться все движения?

А вот и надо проверять режим записи значит тогда

Бывает еще так, что документ проводят, он спотыкается и его записывают. И он записывается со своими недодвижениями. Непроведенный (!)

(0) такое только для новых документов происходит? база на постгре или на мсскуле?

(43)Бывает... Но ооочень редко. Ситуация в (0) гораздо чаще.
Завтра попробую разные варианты.

(44)мсскл.
Да, на новых. Говорю же: когда проводят новый док по ОК - т.е. когда он еще даже не записан.

(46) покури код на тему установить ссылку нового и Записать(), вызываемой уже из транзакции записи

(47) ну и "провести()" :)

(47)Угу. Про это уже подумала.

(38)Кстати, ВСЕ корректные записи имеют одинаковое время, а некорректные чуть раньше. Так что, "чистые" регистры все-таки откатываются.

(49) подсказываю - запускаешь сервер в режиме дебага, открываешь док, включаешь замер производительности, нажимаешь "ок", по завершении - выключаешь замер производительности, смотришь, что откуда вызывается. если кто-то вызывает "Записать" из проведения, для того, чтобы модифицированность пропала (например) - прострели ему коленку....

PosgreSQL?

Работает в связке с PostgreSQL?

(52)Нет.

В общем, устойчиво ситуация эмулируется программно:

ППИ = Док.Скопировать();
НачатьТранзакцию();
ППи.ПолучитьФорму().Открыть();
ППИ.Записать(РежимЗаписиДокумента.Запись);
ППИ.Записать(РежимЗаписиДокумента.Проведение,РежимПроведенияДокумента.Оперативный);
ОтменитьТранзакцию();
ППИ.Записать(РежимЗаписиДокумента.Проведение,РежимПроведенияДокумента.Оперативный);

Я так понимаю, управляемые блокировки не спасут, но риск уменьшат.

Временно решила проблему взведением флага мУдалятьДвижения даже у нового документа.

(53)
Все равно будут не проведенные документы с движениями

(54)Да, от этого не спасет. Но это случается гораздо реже. И будет заметно в работе.

конвертация на 8.2 решит проблему