|
![]() |
#1 |
Axapta Retail User
|
while select зацикливается на одной записи
Возникла ситуация, когда задвоились номера расходных кассовых ордеров, а поскольку они уже были разнесены - то остается только править табличку RcashTrans. Исправлять записей от силы 10, вроде бы ничего сложного:
ttsbegin; while select forupdate RcashTrans where RcashTrans.DocType==1 && (дополнительные ограничения...) { RcashTrans.DocId+="/1"; RcashTrans.doUpdate(); } ttscommit; Но данный запрос работает очень странно - по одной записи он пробегается несколько раз, и номера получаются вида - (номер до испр)/1/1/1/1/1. Переходит к следующей записи видимо поскольку в номер уже больше символы не влазят ![]() В чем загвоздка? ![]() |
|
![]() |
#2 |
Участник
|
Может doUpdate() на update(); заменить?
|
|
![]() |
#3 |
Moderator
|
Дополнительные ограничения в студию!! :)
У меня этот код работает корректно:
PHP код:
|
|
![]() |
#4 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#5 |
Axapta Retail User
|
To Lemming: Уже пробовала, аналогичный эффект.
To DreamCreator: А толку от дополнительных ограничений (они у меня на дату)? Ведь у меня и без них не работает! ![]() Да, Ваш код работает корректно, значит все дело в RcashTrans.doUpdate() (или update() - что без особой разницы)... Завязано все видимо именно на DocID - возможно из-за того что меняем индексное поле? Есть в этом плане какие-то ограничения? |
|
![]() |
#6 |
Axapta Retail User
|
To Vadik:
СУБД MSSQL 2000 версия 2000.80.760.0. Fix немного не подходит - я использую для выборки поле кластерного индекса, поля не кластерных индексов не обновляю. Да и проходит по записи у меня больше двух раз ![]() Хотя возможно действительно дело в чем то подобном и установка последнего SP и решит проблему... Спасибо! |
|
![]() |
#7 |
Участник
|
Все дело в том, что вы изменяете поле, входящее в состав кластерного индекса.
Axapta открывает динамический курсор при использовании forupdate. SQL сервер воспринимает запись с измененным кластерным индексом как новую и добавляет ее в открытый курсор. По-этому при фетче у вас постоянно подтягивается новая запись до тех пор, пока Axapta может изменить значение поля. Что бы обойти этот эффект надо сделать так X++: RCashTrans RCashTrans; RCashTrans RCashTransUpd; ttsbegin; while select RcashTrans where RcashTrans.DocType==1 && ( ...) { RCashTransUpd = RCashTrans::findRecId(RCahsTrans.RecId, True); RcashTransUpd.DocId+="/1"; RcashTransUpd.doUpdate(); } ttscommit; PS 2 Vadik извиняюсь, ссылку на статью заметил уже после написания ответа.
__________________
Axapta v.3.0 sp5 kr2 Последний раз редактировалось AndyD; 30.11.2005 в 10:53. |
|
|
За это сообщение автора поблагодарили: raz (5), Logger (5), FrolovAndy (1). |
![]() |
#8 |
Участник
|
Цитата:
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. Последний раз редактировалось Logger; 05.02.2019 в 14:02. |
|
|
За это сообщение автора поблагодарили: Vadik (1). |