21.12.2010, 00:12 | #1 |
Administrator
|
Группировка по полю GUID
Столкнулся тут с интересным поведением группировки по полю типа GUID в 4.0 и 2009 RU5.
Имеем тестовый джоб X++: static void Job1(Args _args) { Table1 t; ; t.StringField = 'aa'; t.GuidField = newguid(); t.RealField = 2; t.insert(); t.StringField = 'aa'; t.GuidField = newguid(); t.RealField = 2; t.insert(); t.StringField = 'bb'; t.GuidField = newguid(); t.RealField = 2; t.insert(); while select sum(RealField) from t group by StringField, GuidField { info(strfmt("%1 %2 %3", t.StringField, t.GuidField, t.RealField)); } } А вот в DAX 4.0 SP2 нас поджидает сюрприз: Результат одинаковый - независимо от того - временная таблица или постоянная (т.е. есть она в БД или нет). В обоих случаях в качестве СУБД использовался как SQL Server 2005, так и SQL Server 2008 R2. Собственно - вывод - будьте аккуратнее
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 21.12.2010 в 09:31. |
|
|
За это сообщение автора поблагодарили: Logger (2). |
21.12.2010, 01:47 | #2 |
Участник
|
А запрос-то в 4-ке какой уходит на СУБД? А то и в 2009-й надо быть аккуратнее: на RTM-версии, как оказалось, при использовании update_recordset .. setting .. select sum(field) на СУБД уходил запрос без агрегирования Потом это, к счастью, исправили...
|
|
21.12.2010, 09:30 | #3 |
Administrator
|
Вполне ожидаемый исходя из получаемых результатов. Поле GUID тупо игнорируется.
PHP код:
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 21.12.2010 в 09:33. |
|
21.12.2010, 10:42 | #4 |
Участник
|
Какой типа данных у поля GuidField? Допустимо ли в принципе использовать подобный тип данных в качестве поля группировки? Например, группировка по контейнерному полю запрещена.
Если явно указать поле GuidField в списке полей в опции select, что-то изменится? |
|
21.12.2010, 11:12 | #5 |
Administrator
|
GUID. Собственно - из-за этого и возник данный пост.
Цитата:
По контейнерному полю группировка запрещена в первую очередь самой СУБД - т.к. не имеет смысла сравнивать байтики в поле Image (отсюда и запрет на уровне компилятора). А тип GUID - есть в самой СУБД и не ограничен в группировке. Нет. Запрос такой же уйдет.
__________________
Возможно сделать все. Вопрос времени |
|
21.12.2010, 14:36 | #6 |
Участник
|
Я не про это. В MS SQL это поле имеет тип [uniqueidentifier]. Физически - это Binary(16). То, что оно так красиво выглядит - это уже результат специфического преобразования. Ну, как с полями DateTime.
Как следствие, возникает вопрос, была ли предусмотрена корректная обработка (сортировка и группировка) подобных полей в Ax4.0? Судя по тому, что подобное поле просто исключается из списка полей группировки (по аналогии, скажем, с TableId), в Ax4.0 на работу с подобным типом были наложены какие-то дополнительные ограничения, которые были сняты в Ax2009. Хотя и не все. Например, в теме Lookup по полю типа Guid описаны другие проблемы GUID Надо бы посмотреть в справке по Ax4.0 Нет ли каких упоминаний об ограничениях по работе с полями типа GUID. |
|
21.12.2010, 14:43 | #7 |
Administrator
|
Цитата:
Большими буквами чтобы это где-то было написано в явном виде - не видел. Может просто не там смотрел. В любом случае - подозреваю, что я такой могу быть не один который обо этом не знает. Т.е. в данном случае - это не размышление на тему - бага это или фича - а размышления на тему - если захочется группировать в 4-ке по guid-у - то нужно учесть данные особенности.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: Poleax (1), gl00mie (3), johny77 (1). |
Теги |
ax4.0, guid, баг, группировка, ядро |
|
Похожие темы | ||||
Тема | Ответов | |||
sumitax: Creating new GUID in AX2009 | 0 | |||
Lookup по полю типа Guid | 21 | |||
Группировка сводной таблицы Excel | 4 | |||
Группировка в Lookup | 6 | |||
Прочитать сформированный GUID | 2 |
|