Выборка лишних полей ( kr2 )

[belugin]

Почему из

        ret = (select firstOnly startDate from UKS_VillageTask
            where UKS_VillageTask.VillageID == this.VillageID
                  &&
                  UKS_VillageTask.TaskType == _type
        ).startDate;

получается вот такой SQL?

SELECT A.VILLAGEID,A.TASKTYPE,A.STARTDATE,A.ENDDATE,A.ENABLED,A.MODIFIEDDATE,A.MODIFIEDTIME,A.MODIFIEDBY,A.MODIFIEDTRANSACTIONID,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.CREATEDTRANSACTIONID,A.RECVERSION,A.RECID FROM UKS_VILLAGETASK A WITH( INDEX(I_50984VILLAGETASKIDX)) WHERE ((DATAAREAID=?) AND ((VILLAGEID=?) AND (TASKTYPE=?))) OPTION(FAST 2)

CacheLookup == None

[MikeR]

В inside Dax читал что то про то что среда исполнения работает с record и поэтому ей трудно определять какие поля выбираются, из за этого шарашит по всем
Хотя конечно не красиво получается.

[Vadik]

нет под рукой приложения с KR2, но на KR3 и LedgerTrans не воспроизводится

static void fieldListTest(Args _args)
{
    Voucher voucher()
    {
        Voucher     ret;
        ;

        ret = (select firstonly Voucher from LedgerTrans where LedgerTrans.Correct).Voucher;
        return ret;
    }
    ;

    print voucher();
    pause;
}

приводит к

SELECT A.VOUCHER,A.RECID,A.RECVERSION 
FROM LEDGERTRANS A 
WHERE ((DATAAREAID=@P1/*''hrm''*/) AND (CORRECT=@P2/*1*/)) 
OPTION(FAST 2)

[belugin]

Странно, но н других таблицах у меня тоже не воспроизводится.

[belugin]

Путем экспериментов и с помощью других людей выяснилось:
*если в условии только одно поле, которое проиндексированно уникальным индексом - в выборку попадают все поля
*если добавить еще условий то количество полей в выборке снижается, но индексированное поле остается

[gl00mie]

У меня тоже не воспроизвелось, тестировал на SP3 CU1, KR2, KR3, делал выборку CustTable.AccountNum (там есть уникальный индекс по этому полю). Получались такие результаты.
AX 3.0 SP3 CU1, база Oracle (всякие SUBSTR(NLS_LOWER()), видимо - заморочки админов СУБД):

SELECT A.ACCOUNTNUM,A.RECID
FROM   CUSTTABLE A 
WHERE  ((SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER('dat')) AND
   NOT ((SUBSTR(NLS_LOWER(ACCOUNTNUM),1,10)=NLS_LOWER('        00'))))
ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),
         SUBSTR(NLS_LOWER(A.ACCOUNTNUM),1,10)

AX 3.0 KR2, база SQL 2005:

SELECT A.ACCOUNTNUM,A.RECID,A.RECVERSION
FROM   CUSTTABLE A
WHERE ((DATAAREAID='dat') AND NOT ((ACCOUNTNUM='          00')))
ORDER BY A.DATAAREAID,A.ACCOUNTNUM OPTION(FAST 9)

AX 3.0 KR3, база опять Oracle:

SELECT A.ACCOUNTNUM,A.RECID,A.RECVERSION 
FROM   CUSTTABLE A 
WHERE  ((SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER('dat')) AND  
   NOT ((SUBSTR(NLS_LOWER(ACCOUNTNUM),1,10)=NLS_LOWER('        00')))) 
ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),
         SUBSTR(NLS_LOWER(A.ACCOUNTNUM),1,10)

[belugin]

У меня вопсроизводится с EmplTable на kr2 и Ax4 (см. блогпост)
SQL2k5

[belugin]

А почему NOT?

str name=(select name from EmplTable where EmplTable.emplID=='1').name;

[belugin]

для != действительно генерируется корректно

[gl00mie]

Цитата:

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

А почему NOT?

str name=(select name from EmplTable where EmplTable.emplID=='1').name;

С условием на равенство действительно выбирает все поля, по крайней мере на SP3 CU1 и KR2 (базы, соотв., Oracle и SQL 2005)

[belugin]

EmplTable - явно неудачный пример, потому, что там кеширование есть. Но я пробовал и на спеуиально созданной таблице с None

[petr]

Можно попробовать даже на emplTable с уникальным ключом перед выборкой выплнить следующий метод emplTable.disableCache(true). Это во-первых однозначно отправит запрос на сервер, т.е. не будет смотреть в кэш и во-вторых предотвратит выборку всех полей, т.е. будут выбираться только поля, которые указаны в запросе. Т.е. запрос будет работать полностью аналогично тому который получается при выборке с указанием дополнительног условия, кроме range по уникальному индексу.

[belugin]

Интересно, что это (disableCache) работает даже с CacheLookup==None.

Table1 Table1;
;
Table1.disableCache(true);
select field2 from Table1 where Table1.Field1=='';

Правда поле в условии все равно выбирается:

(Table1) SELECT A.FIELD2,A.FIELD1,101090 FROM TABLE1 A WHERE ((DATAAREAID=?) AND (FIELD1=?))

А вот так без индекса:

SELECT A.FIELD2,A.RECID FROM TABLE1 A WHERE ((DATAAREAID=?) AND (FIELD1=?))

[belugin]

Причем при cacheLookup == None кеширования реально не происходит

[petr]

Насчет того, почему Аксапта кэширует записи даже если cacheLookup=None я никакой информации пока не нашел. Возможно она считет, что если есть первичный индекс то кэширование в любом случае надо применять. Но это только предположение.

Как говориться, будем искать...

[petr]

Тогда исправлю в предыдущем посте: не кэширует, а выбирает так как будто собирается кэшировать

[belugin]

Вот воспроизведение на стандартном ф-ле

(select ItemID from InventTrans where 
InventTrans.InventTransID=='s'
&&
InventTrans.InventDimID == '2'
&&
InventTrans.recID==100).ItemID

[EVGL]

Свинство, конечно. Но мне кажется, это - одна из фичей, о которой лучше не знать. Либо надо сразу сообщить о ней в Microsoft. Как заметил мой коллега, если еще держать в уме, что Аксапта будет сопротивляться попыткам повысить ее производительность, жизнь программиста превращается в ад.

[belugin]

Проверю на Ax5 и сообщу в MS через TAP - мне одинг мелкий ненужный баг уже поправили

[petr]

Может быть алгоритм кэширования такой:

1. Если есть первичный индекс, в запросе в условиях равенства по всем полям индекса и нет других полей, и небыло на данной таблично переменной выполнено метода disableCache(true) - тогда "тут возможно кэширование", т.е. смотрим кэш, если в нем есть данная запись берем из кэша ,если нет то "готовимся к кэшированию" (не смотря какой установлен cacheLookup) и в запрос, если в нем выбираются не все поля, добавляем все поля и отправляем такой модифицированный запрос на SQL-сервер.

2. Когда результаты вернулить в зависимость от того, какое кэшироване настроено (например found или none), то либо записать выбранную запись в кэш, либо нет.