[sergeypp]

Уж очень долго выполняются эти операции. Вкрадывается сомнение, что здесь проблема не в очереди диска а в чем то другом.
Не могут ли как то влиять на это включенные опции
Literals in join queries from forms and reports
Literals in complex joins from X++

Еще одна особенность..
вот пример оператора.
exec sp_cursorfetch 180156358, 2, 1, 22
посмотрел описание оператора

sp_cursorfetch [@cursor =] cursor_handle
[, [@fetchtype =] fetchtype]
[, [@rownum =] rownum OUTPUT]
[, [@nrows =] nrows OUTPUT]

[@nrows =] nrows OUTPUT
Is the number of rows to fetch. nrows is int, with a default of NULL (fetch all rows).

Так вот к чему я.. Зависание происходит ТОЛЬКО на запросах у которых @nrows = 22..
Что это означает? Как Axapta генерит эти запросы.. И с чем это связано.. Заранее спасибо за любую инфу.. Уже замучался..