mfp: X++ in AX7: String truncation

[gl00mie]

Цитата:

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

А есть инфа почему так сделали? Юнит тесты неверно работали?

Мне кажется, как раз юнит-тесты все эти годы отрабатывали на ура, и косяки вылезли лишь в реальных проектах. Вроде автор пишет, почему изначально отказ от обрезания значений по EDT был рискованным шагом: допустим, есть у тебя в базе клиентская группа с кодом '0123456789', и пишешь ты код вида

CustGroup   custGroup;
CustGroupId custGroupId = '0123456789abcdefghij'; // допустим, извне пришло длинное значение
select firstonly custGroup where custGroup.CustGroup == custGroupId;
if (custGroup.CustGroup == custGroupId)
{
    info('Bingo!');
}

В AX2012 и ранее у тебя случается Bingo! Код прекрасно находит запись в CustGroup с кодом '0123456789', потому что длинное значение обрезается на присваивании строковой переменной, и в СУБД уходит параметр SQL-запроса "нужной" длины. А вот в D365O у тебя этот код ничего не находит, потому что в СУБД уходит строка 20 символов, которая никогда не окажется равна полю nvarchar(10).

[Logger]

Цитата:

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

В AX2012 и ранее у тебя случается Bingo! Код прекрасно находит запись в CustGroup с кодом '0123456789', потому что длинное значение обрезается на присваивании строковой переменной, и в СУБД уходит параметр SQL-запроса "нужной" длины. А вот в D365O у тебя этот код ничего не находит, потому что в СУБД уходит строка 20 символов, которая никогда не окажется равна полю nvarchar(10).

Небольшая поправочка.

Только что коллега столкнулся с ситуацией когда в ax4 все работало корректно а в 12-ке нет.

Ситуация - find метод на талдычке делает поиск по iso коду из 3 символов. В метод на вызове передали значение 276_1
Значение с кодом 276 в табличке есть. С кодом 276_1 нет и не может быть так как длина строки в столбце 3 символа.

В 4-ке код работает корректно - ничего не находит. В 12-ке находит.
Так происходит, потому что в 4-ке несмотря на объявление строкового типа из 3 символов в переменной реально могло храниться больше символов. А в 12-ке воткнули везде усечение и оно раньше времени усеклось до 3 символов и значение стало "подходить".

В общем видимо 4-ка и 365-я ведут себя одинаково в этом смысле.

В 12-ке даже объявление переменной str 1000 не спасает.
(в вашем примере

str 1000 custGroupId = '0123456789abcdefghij'; // допустим, извне пришло длинное значение

тоже не спасло бы
Видимо усекается где то при выполнении select.
Это совсем ниже пояса как говорится...