Цитата:
Сообщение от
Logger
А есть инфа почему так сделали? Юнит тесты неверно работали?
Мне кажется, как раз юнит-тесты все эти годы отрабатывали на ура, и косяки вылезли лишь в реальных проектах. Вроде автор пишет, почему изначально отказ от обрезания значений по EDT был рискованным шагом: допустим, есть у тебя в базе клиентская группа с кодом '0123456789', и пишешь ты код вида
X++:
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).