Отмена сортировки по умолчанию на форме

[egorych]

Собственно - есть больша-а-а-я таблица - архив sysdatabaselog. Для нее делаю отдельную форму - практически копия стандартной sysdatabaselog.
Проблема в чем - система автоматом подставляет в запрос к БД сортировку по индексу.
Есс-но это очень долго, да и не нужно! Хочется избавиться от этого - пробую

public void executeQuery()
{
    this.query().dataSourceTable(tablenum(SysDatabaseLog_Arh)).sortClear();
    super();
}

Не помогает ! - на сервер все равно уходит -

PHP код:

ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME 


Как избавиться от сортировки?

[DSPIC]

Поставьте у св-ва датасорса AutoQuery = No и сами подсуньте нужную кверю в init() датасорса
или
Ваш код перенесите из executeQuery() в init() поле Super();
или
если уж в executeQuery(), то используйте
this.queryRun().query()...
или
Пропишите в св-ве датасора другой сортировочный индекс, по которому сортироваться будет быстрее. Кстати, если есть индекс - почему медленно сортируется, не совсем понятно...

В общем как-то так...

[Logger]

Если я правильно понимаю, то предполагается что пользователь сам установит нужный фильтр, т.е. показывать форму без фильтра не надо. Может быть поэтому при открытии этой формы сразу вызывать FormdataSource.QueryRun().prompt() или что-нить в этом духе, чтобы пользователь смог проставить нужный фильтр сильно, сужающий выборку.

[DSPIC]

Мне кажется, речь о медленном открытии формы, и как возможную причину рассматривают ненужную сортировку, накладывающуюся автоматически

[sukhanchik]

Сортировка, уходящая на сервер при открытии формы - накладывается не просто так. А для ускорения открытия формы. А именно такая сортировка берется из-за того, что на таблице указан кластерный индекс TableRecIdIdx, который и содержит все эти поля. Кластерный индекс в свою очередь сортирует данные в файле согласно полям, входящим в него. Очевидно, что выбирая с сортировкой по кластерному индексу - выборка будет быстрее (если Вам сказать, что книги в библиотеке лежат согласно сортировке по названию книги = выдать запрос с сортировкой - то Вам легче будет отыскать нужную книгу).

В связи с этим - вопрос к автору топика. С чего Вы решили, что эта сортировка замедляет выборку?

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

[DSPIC]

А какая версия AX, 9-ка? Странная сортировка по SUBSTR... Наверное, sukhanchik прав, а ещё обязательно попробуйте это, если AX2009а

[glibs]

Судя по "...A.CREATEDDATE,A.CREATEDTIME..." версия ниже 5.0.

Согласен с DSPIC

Цитата:

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

... сортировку по индексу. Есс-но это очень долго

Не вижу тут ничего естественного. Сортировка по индексу должна работать быстро.

"OPTION(FAST 1)" у вас на сервер уходит?

Хм. В 4.0 наблюдаю странную вещь. Там на форме 2 источника данных. Оба по таблице SysDataBaseLog. Связи нет. Фильтр на запрос накладывается в методах источника данных.

В результате уходят два запроса.

"
SELECT A.USERNAME,A.DESCRIPTION,A.LOGTYPE,A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.CREATEDTRANSACTIONID,A.RECVERSION,A.RECID,A.DATA
FROM SYSDATABASELOG A WITH( NOLOCK)
WHERE ((DATAAREAID=?)
AND ((TABLE_=?)
AND (LOGRECID=?)))
ORDER BY A.DATAAREAID,A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME OPTION(FAST 1)
"
Выборка по компании, таблице и коду записи. Запрос может венуть много записей по модификации конкретной записи в таблице, но, в общем случае скажем так, умеренно.

"
SELECT A.USERNAME,A.DESCRIPTION,A.LOGTYPE,A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.CREATEDTRANSACTIONID,A.RECVERSION,A.RECID,A.DATA
FROM SYSDATABASELOG A WITH( NOLOCK)
WHERE (DATAAREAID=?)
ORDER BY A.DATAAREAID,A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME OPTION(FAST 1)
"
А вот этим запросом выбираются все данные из таблицы журнала в рамках конкретной компании. Если данных в таблице много (чего можно ожидать), то выборка будет отрабатывать долго и вполне может объяснять торможение формы.

Осталось понять как они этого добились.

[glibs]

Попробуйте открывать форму для конкретной записи через паспорт записи.

Вообще с "OPTION(FAST 1)" открытие формы тормозить не должно сильно.

Смотрите план запроса. разумеется после реиндексации и обновления статистик. Что именно тормозит? И который из двух запросов?

[glibs]

В общем, не там проблему ищете, потому и не находите.

[mazzy]

Может все проще?

Цитата:

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

Собственно - есть больша-а-а-я таблица - архив sysdatabaselog. Для нее делаю отдельную форму - практически копия стандартной sysdatabaselog.
...
Как избавиться от сортировки?

у вас свойство Index у датасорса установлено?
если да, то в соответствии со свойством и сортирует.
Просто уберите.

[AndyD]

Цитата:

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

Странная сортировка по SUBSTR...

Ничего странного - б/д Oracle

[egorych]

Ой, сколько откликов за ночь! Отвечаю по порядку.
Аксапта 3 KR2 на Oracle 10g.
Да, речь идет об медленном открытии формы. Табличка партицированная (~250млн. записей), видимо поэтому order by очень сильно тормозит!
Для 1 записи (или нескольких - история) открывается мгновенно.
Пробовал вставлять sortclear и в init и в execute - результат однинаков т.е. никакого! Попробую еще с подменой query.
Св-во index на датасорсе не заполнено
Статистика и индекс перестроены, пересчитаны и залочены - табличка архивная, заполняется 1 раз в год.
Почему думаю, что тормозит order by? Я собственно не думаю, а знаю - пробовал в разных видах этот запрос делать во внешних тулзах - как только убираешь сортировку - все работает быстро!

[mazzy]

Цитата:

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

Аксапта 3 KR2 на Oracle 10g.

Ух ты, какая древность.
А свойство primary index на самой таблице?

(cluster index пусть остается)

===============
добавлено: у меня только ax3.0 SP6. ни в исходном слое, ни в SP6 в свойствах не установлен Primary Index. А вот в SP2 - не помню.

[egorych]

Цитата:

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

Ух ты, какая древность.
А свойство primary index на самой таблице?
(cluster index пусть остается)

И primary и cluster - все поля пустые!
В том и вопрос, что все известные мне способы отмены сортировки почему-то не работают!

[AndyD]

Цитата:

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

Ух ты, какая древность.
А свойство primary index на самой таблице?

(cluster index пусть остается)

===============
добавлено: у меня только ax3.0 SP6. ни в исходном слое, ни в SP6 в свойствах не установлен Primary Index. А вот в SP2 - не помню.

Индекс TableRecIdIdx - не является уникальным. Соотвественно, не может быть и первичным

Да и зачем нужен, в данном случае, Primary Key?


У меня другой вопрос.
Каким образом хранятся в кластерном индексе рассчитанные значения для функционального ключа? И как упорядочиваются записи по нему?

[AndyD]

Цитата:

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

И primary и cluster - все поля пустые!
В том и вопрос, что все известные мне способы отмены сортировки почему-то не работают!

Интересно.
У меня в конфиге из подписи кластерный индекс есть

А если таблицу просматривать в Обозревателе из Аксапты - тоже тормозит, или открывает быстро?

[egorych]

Цитата:

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

Индекс TableRecIdIdx - не является уникальным. Соотвественно, не может быть и первичным

Да, это так, но т.к. индекс на таблице 1, то система добавила к нему RecID автоматом и получился уникальный индекс.

Цитата:

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

У меня другой вопрос.
Каким образом хранятся в кластерном индексе рассчитанные значения для функционального ключа? И как упорядочиваются записи по нему?

Не совсем понял вопрос? Косяпта, как известно, в случае Оракла использует т.н. FBI и, соответственно в запросах также использует обертку для строковых полей из NLS_LOWER и SUBSTR, поэтому индексы используются нормально. Это то очем спрашивали?

Цитата:

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

А если таблицу просматривать в Обозревателе из Аксапты - тоже тормозит, или открывает быстро?

Тоже тормозит - на сервере запрос получается все равно с order by !

[tricky]

может быть это поможет

[mazzy]

Цитата:

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

Да и зачем нужен, в данном случае, Primary Key?

Спрашиваю, потому что автор не сказал ни о версии, ни модификациях.
теперь мы можем быть уверены, что индексов в свойствах нет ни на форме, ни в таблице.

но ведь барабашки - нет!

значит, остаются какие-то непонятнки с ядром ax3.0 SP2.
Насколько я помню, SP2 глючный какой-то был. Мы старались обновлять клиентов до SP3, а потом хотя бы до Kernel Rollup 2. В KR2 много чего поправлено в ядре было.

egorych, у вас точно exe-шники от ax3.0 SP2?
или вы exe-шники таки обновляли?
что показывается в окне Помощь \ О программе?

можете скриншот привести?
щас мы вашу версию определим http://forum.mazzy.ru/index.php?showtopic=881

заодно, вы пробовали обновлять exe-шники до SP5? можете попробовать на тестовой базе и сообщить о результатах? может это багофича ядра какая-нибудь.

[AndyD]

Цитата:

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

значит, остаются какие-то непонятнки с ядром ax3.0 SP2.
Насколько я помню, SP2 глючный какой-то был. Мы старались обновлять клиентов до SP3, а потом хотя бы до Kernel Rollup 2. В KR2 много чего поправлено в ядре было.

egorych, у вас точно exe-шники от ax3.0 SP2?
или вы exe-шники таки обновляли?
что показывается в окне Помощь \ О программе?

У него в подписи
Axapta 3.0 sp - хз какой, kr2
Что-то сомневаюсь, что там sp2