while select зацикливается на одной записи

[ViV]

Возникла ситуация, когда задвоились номера расходных кассовых ордеров, а поскольку они уже были разнесены - то остается только править табличку RcashTrans. Исправлять записей от силы 10, вроде бы ничего сложного:

ttsbegin;
while select forupdate RcashTrans
where
RcashTrans.DocType==1 &&
(дополнительные ограничения...)
{
RcashTrans.DocId+="/1";
RcashTrans.doUpdate();
}
ttscommit;

Но данный запрос работает очень странно - по одной записи он пробегается несколько раз,
и номера получаются вида - (номер до испр)/1/1/1/1/1. Переходит к следующей записи видимо поскольку в номер уже больше символы не влазят Никаких сообщений при запуске не выдается...
В чем загвоздка?

[Lemming]

Может doUpdate() на update(); заменить?

[DreamCreator]

У меня этот код работает корректно:

PHP код:

static void testRCashTrans(Args _args)
{
    RCashTrans  rCashTrans;
    int         i;
    ;
    while select RcashTrans
        where rCashTrans.DocType==1
    {
        RcashTrans.DocId+="/1";
        info(strfmt('%1',RcashTrans.DocId));
        i++;
        if(i > 10)
            break;
    }
} 


А у Вас?

[Vadik]

СУБД? Версия?
http://support.microsoft.com/kb/843267/EN-US/
?

[ViV]

To Lemming: Уже пробовала, аналогичный эффект.

To DreamCreator:
А толку от дополнительных ограничений (они у меня на дату)?
Ведь у меня и без них не работает!
Да, Ваш код работает корректно, значит все дело в RcashTrans.doUpdate() (или update() - что без особой разницы)...
Завязано все видимо именно на DocID - возможно из-за того что меняем индексное поле? Есть в этом плане какие-то ограничения?

[ViV]

To Vadik:

СУБД MSSQL 2000 версия 2000.80.760.0.
Fix немного не подходит - я использую для выборки поле кластерного индекса, поля не кластерных индексов не обновляю. Да и проходит по записи у меня больше двух раз
Хотя возможно действительно дело в чем то подобном и установка последнего SP и решит проблему...
Спасибо!

[AndyD]

Все дело в том, что вы изменяете поле, входящее в состав кластерного индекса.

Axapta открывает динамический курсор при использовании forupdate. SQL сервер воспринимает запись с измененным кластерным индексом как новую и добавляет ее в открытый курсор. По-этому при фетче у вас постоянно подтягивается новая запись до тех пор, пока Axapta может изменить значение поля.

Что бы обойти этот эффект надо сделать так

RCashTrans    RCashTrans;
RCashTrans    RCashTransUpd;
ttsbegin;
while select RcashTrans
where
RcashTrans.DocType==1 &&
( ...)
{
    RCashTransUpd = RCashTrans::findRecId(RCahsTrans.RecId, True);
    RcashTransUpd.DocId+="/1";
    RcashTransUpd.doUpdate();
}
ttscommit;

И еще в LedgerJournalTrans.RCashDocId также заносится номер кассового ордера

PS 2 Vadik извиняюсь, ссылку на статью заметил уже после написания ответа.

[Logger]

Цитата:

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

Все дело в том, что вы изменяете поле, входящее в состав кластерного индекса.

Axapta открывает динамический курсор при использовании forupdate....

Недавно попался документ (см. вложение со стр.103 взято тут
https://docplayer.net/48015368-Sqlca...al-engine.html
или
http://download.microsoft.com/downlo...l%20Engine.pdf
)
там сказано буквально следующее:

Цитата:

Pessimistic Concurrency Considerations Currently,
X++ SELECT statements issued under AX’s pessimistic locking will request a dynamic cursor and not a FFO cursor, so we recommend: optimistic locking for this reason in addition to the concurrency benefits it provides. There is a pending design change in AX4, AX2009 and the future AX6 that will request FFO cursors even when pessimistic locking is used. An announcement of this change will be made on the AX Performance blog: http://blogs.msdn.com/axperf when completed.

т.е. собирались даже исправить.