AX2009 и FETCH API_CURSOR

[demianimp]

Дополню, что если запрос выполнить на SQL. Без участия аксапты, то выдает все данные быстро.

[mazzy]

Цитата:

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

Дополню, что если запрос выполнить на SQL. Без участия аксапты, то выдает все данные быстро.

Какая нехорошая девочка! Не получит подарки на новый год. И корпоратив проводите "Без участия аксапты"

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

типа в одном цикле пытается "получить сальдо" по счету на дату и разнести какую-нибудь коррекцию на этот же счет.
точно никто не вызывал метод selectForUpdate(true) на таблице, которая участвует в читающем запросе, который вы привели в первом посте?

[trud]

Цитата:

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

Дополню, что если запрос выполнить на SQL. Без участия аксапты, то выдает все данные быстро.

О.. тогда у вас скорее всего проблема parameters sniffing. Поставьте хинт forceliterals в запрос, тогда должно быть одинаково. Ну или индекс

[demianimp]

Цитата:

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

Какая нехорошая девочка! Не получит подарки на новый год. И корпоратив проводите "Без участия аксапты"

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

типа в одном цикле пытается "получить сальдо" по счету на дату и разнести какую-нибудь коррекцию на этот же счет.
точно никто не вызывал метод selectForUpdate(true) на таблице, которая участвует в читающем запросе, который вы привели в первом посте?

Нет, в джобе только select (вывод данных в файл для анализа)

Цитата:

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

О.. тогда у вас скорее всего проблема parameters sniffing. Поставьте хинт forceliterals в запрос, тогда должно быть одинаково. Ну или индекс

Не помог forceliterals.

[Владимир Максимов]

Цитата:

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

Дополню, что если запрос выполнить на SQL. Без участия аксапты, то выдает все данные быстро.

Вы неправильно их готовите

Физически, Aхapta всегда оборачивает запрос в курсор-SQL, а план выполнения для курсора может принципиально отличаться от плана выполнения для запроса

Т.е. для целей тестирования именно производительности запроса в SQL надо делать так

DECLARE test CURSOR FOR 
select *
from ledgerTrans with (index (ACDate))     //Имя индекса будет другое
where ledgerTrans.dataAreaId = 'dat'         // Если есть dataAreaId
	and ledgerTrans.AccountNum = "AccountNum"
    and ledgerTrans.TransDate  <= '20200229'
    and ledgerTrans.Posting    = 14		--LedgerPostingType::LedgerJournal


open test
// Тормоза ожидаются вот здесь
FETCH NEXT FROM test

//Перебор записей
WHILE @@FETCH_STATUS = 0
begin

	FETCH NEXT FROM test
end

CLOSE test
DEALLOCATE test

И вот это уже у этого надо смотреть план выполнения запроса и замерять время выполнения.

Правда обычно тормоза бывают на самом первом шаге. На самом первом FETCH. Дальше обычно все быстро идет. Если же тормоза наблюдаются в процессе перебора записей, то попробуйте для начала перестроить индексы...