|
12.03.2019, 15:50 | #1 |
Moderator
|
Версия 8.1.3, метод SSRSReportRunController.CheckBatchJobStatus() содержит следующий замечательный код:
X++: UserConnection userConnection; try { userConnection = new UserConnection(); userConnection.ttsbegin(); // Update teh batch job status to 'Waiting' select pessimisticLock firstonly * from batchJobUpdate where batchJob.RecId == batchJobUpdate.RecId; if (batchJobUpdate) { batchJobUpdate.Status = BatchStatus::Waiting; batchJobUpdate.update(); } userConnection.ttscommit(); } finally { userConnection.finalize(); } Лечится это достаточно простым путем: Надо найти в вашей системе батч с именем "Report Data Cleanup" и просто его удалить. При следущей печати отчета, система прокашляется и создаст нужный батч. |
|
|
За это сообщение автора поблагодарили: Vadik (1), trud (5), gl00mie (5). |
12.03.2019, 18:55 | #2 |
Banned
|
Цитата:
Или там насквозь хитрый batchJobUpdate.update() который сам себе write() ? если писать batchJobUpdate.setConnection(userConnection)) то это скроет ошибку за счет нового соединения. Так? |
|
12.03.2019, 19:00 | #3 |
Moderator
|
Ну по факту, вообще обновлять batchJob в рамках текущего соединения - негуманно. Он там будет заблокирован на какое-то время и я не уверен что батч сервер будет себя корректно вести в такой ситуации. Просто учитывая что они в userConnection начинают и завершают транзакции, а в обычном дефолтном соединении - нет, они действительно просто забыли табличку к userConnection присоединить.
|
|