ttsbegin и зацикливание While select

[Perc]

Ранее еще с тройки время от времени использовал такую конструкцию например:

ttsbegin;
while select ledgerJournalTrans {
  i++;
  ...
  if (i mod 100 == 0) {
    ttscommit;
    ttsbegin;
  }
}
ttscommit;

и как то не помню чтобы сталкивался с проблемой. А тут вдруг столкнулся с зацикливанием. Гдето после 110-120 записи ledgerJournalTrans начинает выборку с начала. Причем в моем данном, случае внутри цикла ledgerJournalTrans вообще никак не менялся. Был в недоумении. Пришлось задуматься. Переписал на:

while select ledgerJournalTrans {
  i++;
  if (first) {
    ttsbegin;
    first = false;
  }
  ...
  if (i mod 100 == 0) {
    ttscommit;
    ttsbegin;
  }
}
if (!first)
  ttscommit;

Все заработало нормально. В чем вопрос?
Да так.. просто хотелось узнать от спецов по работе с СУБД физику процесса)

[Vadik]

Цитата:

просто хотелось узнать от спецов по работе с СУБД физику процесса

AX использует динамические курсоры. Если в процессе обработки меняется физическое местоположение записи (например, обновляется поле входящее в состав кластерного индекса или происходит расщепление страниц) запись может "дофетчиться" курсором повторно. Лечится разными способами - например, принудительной сортировкой по полям для которых гарантируется неизменность (например RecId)

[Perc]

Цитата:

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

AX использует динамические курсоры. Если в процессе обработки меняется физическое местоположение записи (например, обновляется поле входящее в состав кластерного индекса или происходит расщепление страниц) запись может "дофетчиться" курсором повторно. Лечится разными способами - например, принудительной сортировкой по полям для которых гарантируется неизменность (например RecId)

Ну вот мои наблюдения с данным джобом противоречат этому тезису. Джоб конечно задумывался для обновления кое-каких записей. Но в моем случае оказалось что вообще не одна запись не обновлялась - ни этим джобом, ни кем либо вообще в этот момент в базе. Но тем не менее зацикливание произошло.
Более того наблюдал обратную ситуации в подобном цикле. Записи удалялись внутри цикла удовлетворяющие условию селекта. Но цикл все равно перебирал непонятно откуда взятые уже удаленные записи.

[AndyD]

Цитата:

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

Более того наблюдал обратную ситуации в подобном цикле. Записи удалялись внутри цикла удовлетворяющие условию селекта. Но цикл все равно перебирал непонятно откуда взятые уже удаленные записи.

Аксапта закачивает данные порциями - по всей видимости, то что было удалено уже было прочитано и находилось в кэше

[S.Kuskov]

Цитата:

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

Аксапта закачивает данные порциями - по всей видимости, то что было удалено уже было прочитано и находилось в кэше

На сколько я понял, удаление производилось непосредственно в той же сессии что и чтение. Т.е. по логике удаление не должно было бы пройти мимо кэша. Кстати, а о каком кэше речь? В общем, непонятна...
Ещё обсуждение похожего вопроса Как должен работать такой запрос

Создается впечатление, что эти динамические курсоры имеют квантовую природу. Прямо-таки корпускулярно-волновой дуализм, какой-то. В одних случаях они фиксируют выборку перед её обходом, а в каких-то меняют её по ходу выполнения. Но сдается мне, что эта неопределенность в СУБД сидит, а не в аксапте.