Ivan_Pisarevskyчто вызовет полное кэширование резалтсета и сортировку через темп файл,т.е. это такой хак, чтобы стабилизировать курсор.

Любопытные приёмчики...

А если бы в исходном цикле поменять условие на сам курсор?




тогда бы могло зациклиться?

возможно, для двойки это был бы более очевидный хак

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

А, ещё старый добрый хак

hvlad,

я тоже не вполне понимаю, почему ТС начал цикл городить, вместо того, чтобы просто запустить UPDATE
похоже на него так со всех сторон насели, что мозг заклинило, включилось туннельное зрение, бывает, брррр!

но он начал с цикла, так что мне стало любопытно сделать именно его изначальный цикл работающим с минимальными изменениями в запросе.

И да, where current - именно чтобы не искать запись ещё раз, тем более full-scan'ом, аналог прямогo update.

Но тут снова вопрос к implementation details.
Любое изменение - это новая версия строки.

Не может ли так получиться, что update вставит новую версию записи в свободное место впереди курсора, после чего бегущий fullscan'ом цикл снова на нее наткнётся?

Вроде краем уха слышал, что записи помечались, что они изменены текущим оператором, чтобы этого избежать, но где когда и что слышал, не помню.

Симонов Денис,

а в 2.х ?

может вышеупомянутый update ( отдельный или внутри цикла ) снова зацепить созданные сами собой записи ?

а update с where видимо опять может...

3.0 relnotescontinue updating the same rows ad infinitum ..... because the engine used an implicit cursor for the operations.

Симонов Денисupdate без where нет

а почему, интересно?

предположим, на текущей сранице свободного места нет.
оператор изменённую запись записывает в свободное место на следующую страницу.
а если после restore - так и вообще на чистую новую страницу в конец таблицы.

....через некоторое время update который fullscan заканчивает текущую страницу, добирается до следующей - а там новая изменённая версия ему снова попадается.