простейший job уходит в бесконечный цикл

[Keen]

Понадобилось вручную подправить несколько десятков номеров ваучеров в неразнесённых журналах, т.к. из-за копирования из другой компании номера задвоились. Написал левой ногой простенький одноразовый джоб, а он почему-то уходит в бесконечный цикл. Реально записей таких меньше сотни. При отборе непосредственно из LedgerJournalTrans по RecId всё отлично отрабатывает. Где могут крыться грабли? Или я к полуночи пятницы уже просто зверски туплю?

static void LJ_VoucherRefresh(Args _args)
{
    LedgerJournalTable      ljt;
    LedgerJournalTrans      ljtr;
    int num = 212;
    ;
    ttsbegin;
    while select ljt where ljt.Posted == false
    {
        while select forupdate ljtr where ljtr.JournalNum == ljt.JournalNum
        {
            num++;
            ljtr.Voucher = strfmt("V0000%1", num);
            ljtr.doUpdate();
        }
    }
    ttscommit;
}

P.S. Стоит SP3 Critical Update 1 Build #9.3, билд ядра #1951.2410/514-193.

[Eldar9x]

а для чего транзакция на внешнем уровне? Попробуйте написать так:

static void LJ_VoucherRefresh(Args _args)
{
    LedgerJournalTable      ljt;
    LedgerJournalTrans      ljtr;
    int num = 212;
    ;
    while select ljt where ljt.Posted == false
    {
    ttsbegin;
        while select forupdate ljtr where ljtr.JournalNum == ljt.JournalNum
        {
            num++;
            ljtr.Voucher = strfmt("V0000%1", num);
            ljtr.doUpdate();
        }
    ttscommit;
    }
}

кроме того,
можно попробовать изменить присваивание:
ljtr.Voucher = strfmt("V0000%1", num);
и так ли нужно делать doUpdate (чем не катит update())

[Keen]

Да, таким образом транзакцию обозначать тоже пробовал - зацикливается на первом же журнале. И update() пробовал ставить - результат тот же.

[belugin]

Попробуйте пострассировать SQL - возможно, есть какие-то циклические delete actions?

(может быть стоит их скипануть)

[Lemming]

Сталкивался с таким поведением. Поэтому присоеденяюсь к вопросу автора.

WorkAround:
Keen я так полагаю, что у Вас в определенном журнале/журналах перехлестнулись Документы ГК. Вроде бы это известный глюк. И если время не ждет, то напишите Job, который создаст точную копию проблемного журнала/журналов, но с новыми номерами ГК.

[db]

while select forupdate ljtr where ljtr.JournalNum == ljt.JournalNum
order by RecId
не спасет случайно?
Скорее всего SQL server в своих потрохах как то использует в этом запросе индекс VoucherIdx, который вы корячите увеличивая поле Voucher и обновленные записи снова попадают в выборку

[Stitch_MS]

Цитата:

Сообщение от db

order by RecId
не спасет случайно?

В точку