Аксапта ограничивает размер строки-маски в операторе like размером фильтруемого поля

[S.Kuskov]

Обнаружил сейчас неприятную особенность оператора like. Заключается она в следующем.

Допустим в таблице есть поле длиной 10 символов. В нём хранится значение занимающее полностью весь столбец, т.е. тоже длиной в 10 символов. Допустим это
"ABC0123456". Если попытаться отфильтровать его по условию like "*ABC0123456", то в результате получим пустую выборку. Потому что, на самом деле маска длиной 11 символов обрезается справа до длины поля, т.е до 10. В результате маска превращается в "*ABC012345".И если в таблице будут записи удовлетворяющие этому обрезанному критерию, то они выберутся. Если в маску добавить две звёздочки, то соответственно справа обрежутся уже два символа.

В начале я подумал, что это Аксаптовские проделки, но поэкспериментировав на SQL сервере обнаружил что проблема глубже.

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

В случае временных таблиц, работу с которыми аксапта реализует самостоятельно, всё работает корректно.

[Logger]

Версия Аксапты, версия сиквела ?

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

А Вы не записываете маску в переменную? Может, проблема с типом данных той переменной, в которую записали маску?

str 3 testVar = "1234";
;

print testVar;
pause;

[S.Kuskov]

AX2009 SP1
SQL Server 2008 R2

static void JobTestLike20110217(Args _args)
{
//    TableTestLike.Field1 StringSize 10

    TableTestLike TableTestLike;
    Range mask = '*ABC0123456';
    ;
    
    delete_from TableTestLike;
    
    TableTestLike.clear();
    TableTestLike.Field1 = 'ABC0123456';
    TableTestLike.insert();

    TableTestLike.clear();
    TableTestLike.Field1 = 'ABC012345';
    TableTestLike.insert();
    
    info(strfmt('mask: %1', mask));
    while select TableTestLike
    where
        TableTestLike.Field1 like mask
    {
        info(TableTestLike.Field1);
    }
}

[TasmanianDevil]

Мда ...
Явно не в переменной дело, да и не в сервере очень даже может быть.
Вариант того, что особо "одаренное" ядро может обрезать строку ограничения до размерности поля в репозитарии, выдавая такого "кастрата" на сервер, рассматривался ? "Кастрат", я так понимаю, обнаружился при трассировке переданного системой запроса ?

[S.Kuskov]

В том то и дело что результат выполнения такого запроса в SQL Server Management Studio точно такой же. Т.е. ошибка не в аксапте а в СУБД

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

Профайлер SQL-сервера показывает, что на сервер попадает уже обрезанное значение. Т.е. действительно это ошибка ядра Axapta. И действительно искомое значение обрезается до размерности поля в репозитарии

Например, для следующего запроса профайлер SQL-сервера показывает, что в качестве параметра передается только первые 10 символов константы

    while select TableTestLike
    where
        TableTestLike.Field1 == 'ABC0123456890123456789'
    {
        info(TableTestLike.Field1);
    }

[gl00mie]

Можно обойтись без профайлера SQL, ограничившись штатной трассировкой запросов, если в запросе использовать hint forceliterals. Хотя в запросе с литералами и без них может получиться разное значение маски

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

Цитата:

Сообщение от S.Kuskov

В том то и дело что результат выполнения такого запроса в SQL Server Management Studio точно такой же. Т.е. ошибка не в аксапте а в СУБД

Нет. Вот как раз в Management Studio все в порядке. Запрос вида

select * from TableTestLike
where TableTestLike.Field1 like '%ABC0123456'

Вернет то, что и должен вернуть. Именно запись с 6 на конце.

Microsoft SQL Server 2005 - 9.00.4285.00 (Intel IA-64) Feb 8 2010 23:35:42
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

----------------------

Даже с учетом того, что MS SQL выполняет не прямой запрос, в фетчит курсор, все-равно все в порядке

DECLARE @Field1 varchar(10)

DECLARE cursor1 CURSOR FOR
SELECT Field1 
FROM TableTestLike
where Field1 like '%ABC0123456'

OPEN cursor1
FETCH NEXT FROM cursor1 into @Field1 
WHILE @@FETCH_STATUS = 0
   BEGIN
	select 'cursor1', @Field1 
      FETCH NEXT FROM cursor1 into @Field1 ;
   END;
CLOSE cursor1
DEALLOCATE cursor1

[Logger]

Что же делать ?
QueryRun нас спасет ?

[S.Kuskov]

Да на SQL Server я зря наговаривал (видимо я в попыхах перепутал процент со звёздочкой), там всё в порядке, чего не скажешь про аксапту

Цитата:

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

Что же делать ?
QueryRun нас спасет ?

Неа

static void JobTestLike20110217(Args _args)
{
//    TableTestLike.Field1 StringSize 10
    Query Query;
    QueryRun QueryRun;


    TableTestLike TableTestLike;
    Range mask = '*ABC0123456';
    ;

    delete_from TableTestLike;

    TableTestLike.clear();
    TableTestLike.Field1 = 'ABC0123456';
    TableTestLike.insert();

    TableTestLike.clear();
    TableTestLike.Field1 = 'ABC012345';
    TableTestLike.insert();

    info(strfmt('mask: %1', mask));
    while select TableTestLike
    where
        TableTestLike.Field1 like mask
    {
        info(TableTestLike.Field1);
    }

    Query = new Query();
    Query.addDataSource(tablenum(TableTestLike)).addRange(fieldNum(TableTestLike, Field1)).value(mask);
    QueryRun = new QueryRun(Query);
    while(QueryRun.next())
    {
        TableTestLike = QueryRun.get(tablenum(TableTestLike));
        info(TableTestLike.Field1);
    }
}

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

Цитата:

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

Можно обойтись без профайлера SQL, ограничившись штатной трассировкой запросов, если в запросе использовать hint forceliterals. Хотя в запросе с литералами и без них может получиться разное значение маски

Да, хинт forceliterals спасает положение. Но только если использовать переменные

  while select forceLiterals TableTestLike
    where
        TableTestLike.Field1 like mask
    {
        info(TableTestLike.Field1);
    }

Если же вместо переменной использовать константу. Т.е. писать запрос так

  while select forceLiterals TableTestLike
    where
        TableTestLike.Field1 like '*ABC0123456'
    {
        info(TableTestLike.Field1);
    }

То вне зависимости от использования хинта forceliterals или forceplaceholders на сервер уходит запрос вида

SELECT *
FROM TableTestLike
WHERE (Field1 like '\%ABC0123456' ESCAPE '\' )

Подобный запрос вообще ничего не возвращает. Но здесь проблема в обратном слеше и действительно уже в собственно MS SQL. Очевидно, происходит не корректное исключение этого самого слеша из условия отбора

[S.Kuskov]

Просьба модераторов изменить заголовок темы
SQL Server Аксапта ограничивает размер строки-маски в операторе like размером фильтруемого поля

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

Просьба модераторов изменить заголовок темы
SQL Server Аксапта ограничивает размер строки-маски в операторе like размером фильтруемого поля

Сделано