баг в 2.5. Будьте осторожнее с символом "_" подчеркивание

[levsha]

Создал string EDT Type1 размером 10 символов. Создал табличку Table1 с двумя текстовыми полями Field1 и Field2 типа Type1. Добавил в табличку запись "1_2_3_4_5", "6_7_8".
Написал джобик:

static void Job300(Args _args)
{
Table1 table;
Query q = new Query();
QueryBuildDataSource qbds = q.addDataSource(tableNum(Table1));
QueryBuildRange qbr = qbds.addRange(fieldNum(Table1,Field1));
Type1 value = '1_2_3_4*';
Type1 value2 = '6_7_8';
QueryRun qr;
;
qbr.value(value);
qbr = qbds.addRange(fieldNum(Table1, Field2));
qbr.value(value2);
select table where (table.Field1 like value) && (table.Field2 == value2);
print table.Field1;
pause;
qr = new QueryRun(q);
while (qr.next())
{
print 'uraaaa';
}
pause;
}

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

Изменил значение value на "1_2_3_*" - все в порядке, джобик отрабатывает правильно в обоих случаях. Если же оставить value прежним и убрать вторую часть фильтра по полю Field2 - тоже все в порядке, если поменять местами фильтры(говорят от перемены мест слагаемых сумма не меняется) - опять будет хорошо отрабатывать.

Решил посмотреть какие параметры приходят на sql server. Так вот символ подчеркивание "_" по какой-то причине аксаптой (именно в случае like) преобразуется в "\_" как будто это какой-то специальный символ (хотя нигде не слышал до сих пор, чтобы подчеркивание был каким-то спец символом). Когда приходит запрос, в котором стоит like со значением, в котором общее количество всех символов плюс число подчеркиваний превышает указанную длину поля(в нашем примере 10), а после like через "и"(через "или" - опять же все в порядке)присоединен еще какой-нибудь фильтр по другому полю, то происходит глюк - значение фильтра по первому полю обрезается максимальным числом символов в этом поле плюс один(при условии, что теперь в этом значении фильтра добавлены слэши) и к этому значению присоединяется значение следующего фильтра (то есть в приведенном выше примере - получаются параметры фильтра "1\_2\_3\_4%6_7_8", "6_7_8"). Если с учетом слэшей количество символов не превышает размер поля - то все в порядке. Баг мне кажется достаточно критичным - так как у нас широко используются символы "_" в кодах клиентов, кодах поставщиков, кодах номенклатуры(длина полей, которых составляет всего 20 символов) и в запросах, подобных приведенному выше по этим кодам может в каких-то случаях теряться информация.

К сожалению нет под рукой трешки, чтобы проверить этот баг в ней.
Сам имею в распоряжении:
Axapta 2.5, sp6,
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)