AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.12.2007, 14:10   #1  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
? if (record) в случае join с использованием group by
Выполните у себя такое вот задание - только убедитесь что номенклатура, которая указана в макросе выше, есть в остатках на каком-то складе.
X++:
static void testIfCursorBuffer(Args _args)
{
    InventSum   inventSum;
    InventDim   inventDim;
    #define.ItemId("ESB-009")
    ;
    select inventDim
        group by InventLocationId
        join sum(AvailPhysical) from inventSum
            group by ItemId
            where inventSum.ItemId == #ItemId &&
            inventDim.inventDimId == inventSum.InventDimId;

    print inventSum.AvailPhysical;
    print inventDim.InventLocationId;
    
    if (inventSum)
        print "InventSum";
        
    if (inventDim)
        print "InventDim";

    pause;

    select sum(AvailPhysical) from inventSum
        group by ItemId
        where inventSum.ItemId == #ItemId
        join inventDim
            group by InventLocationId
            where inventDim.inventDimId == inventSum.InventDimId;

    print inventSum.AvailPhysical;
    print inventDim.InventLocationId;
    
    if (inventSum)
        print "InventSum";
        
    if (inventDim)
        print "InventDim";

    pause;
}
Результаты получаются такие:

1) before first pause:

4500
MW
InventDim

2) before second pause:

4500
MW
InventSum

Кто что думает про такое поведение?
В смысле про то, что вторая запись из join является не-проинициализированной с точки зрения АХ?
Старый 07.12.2007, 14:24   #2  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Судя по всему, вторая таблица в запросе не ассоциируется с курсором для такого запроса и проверяется по recId.

Как выход - добавлять агрегирующую функцию для recId
__________________
Axapta v.3.0 sp5 kr2
Старый 07.12.2007, 14:29   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от kashperuk Посмотреть сообщение
В смысле про то, что вторая запись из join является не-проинициализированной с точки зрения АХ?
Дык, и первая тоже.
значения в полях, не указаных в group by и в агрегирующих функциях, не определены.

Т.е. в указанных запросах recid может иметь любое значение, в том числе и нулевое.
__________________
полезное на axForum, github, vk, coub.
Старый 07.12.2007, 14:30   #4  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от AndyD Посмотреть сообщение
Как выход - добавлять агрегирующую функцию для recId
Я работаю с запросом с формы, то есть с содержимым грида, если быть более точным.
И запрос менять не могу.

Получается, когда я беру

inventDim_ds.cursor()

а потом проверяю

if (inventDim) - получаю, что нету InventDim

Меня интересует в этом контексте - должно ли так быть? Или АХ должна учитывать эту ситуацию?
Старый 07.12.2007, 14:32   #5  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от mazzy Посмотреть сообщение
Дык, и первая тоже.
значения в полях, не указаных в group by и в агрегирующих функциях, не определены.

Т.е. в указанных запросах recid может иметь любое значение, в том числе и нулевое.
RecId = 0, и это и ожидается
но проверка if (record) работает по-другому, не через RecId
Старый 07.12.2007, 14:43   #6  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Любопытно почему все таки Аксапта не проверила непустоту значений во втором датасорсе. Мне всегда казалось, что если в запросе с группировками есть хоть одно поле непустое, то проверка

X++:
if (common)
даст true
Старый 07.12.2007, 14:47   #7  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
2 kashperuk

Ну, так как запрос соединяется по inner join, то достаточно проверить InventSum.
__________________
Axapta v.3.0 sp5 kr2
Старый 07.12.2007, 14:54   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от kashperuk Посмотреть сообщение
RecId = 0, и это и ожидается
но проверка if (record) работает по-другому, не через RecId
Не. Ты проверяешь таблицу, Аксапта выполняет неявное преобразование к boolean.
Где-то здесь писали про ошибку в каких-то сервис-паках о том, что отрицательное четное целое неправильно преобразуется в true/false.
__________________
полезное на axForum, github, vk, coub.
Старый 07.12.2007, 15:04   #9  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
X++:
static void Job306(Args _args)
{
    inventSum       inventSum;
    ;
    select inventSum
    group by
    InventDimId
    ;
    if (inventSum)
        info('inventSum');

    if (inventSum.data())
        info('inventSum.data()');

    select inventSum
    group by
    InventDimId
    , recid
    ;
    if (inventSum)
        info('inventSum recID');

    if (inventSum.data())
        info('inventSum.data() recID');


}
получается что Аксапта при проверке
if (common)
проверяет есть ли связанный с буфером курсор или отличное от нуля значение recId - тогда возвращает true
иначе false

Последний раз редактировалось Logger; 07.12.2007 в 16:31.
Старый 07.12.2007, 15:11   #10  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от Logger Посмотреть сообщение
Любопытно почему все таки Аксапта не проверила непустоту значений во втором датасорсе. Мне всегда казалось, что если в запросе с группировками есть хоть одно поле непустое, то проверка

X++:
if (common)
даст true
Так и есть - но только для незаджойненных таблиц

Цитата:
Сообщение от AndyD Посмотреть сообщение
2 kashperuk

Ну, так как запрос соединяется по inner join, то достаточно проверить InventSum.
Да, вариант.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Не. Ты проверяешь таблицу, Аксапта выполняет неявное преобразование к boolean.
Где-то здесь писали про ошибку в каких-то сервис-паках о том, что отрицательное четное целое неправильно преобразуется в true/false.
Может быть - но тут, имхо, проблема не в этом. А в том, что АХ использует другую проверку для основной таблицы и для подчиненных в соединении по иннержоин
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
if (record) vs if (record.RecId) kashperuk DAX: Программирование 18 27.11.2008 18:53
jerry-dynamics: How can you make sure that the end user can not delete a record in one table if there are related records in another table? Blog bot DAX Blogs 0 16.06.2007 11:20
Fred Shen: Always use recId to know if a select statement returns a record Blog bot DAX Blogs 0 28.10.2006 16:40
InventJournalTrans DreamCreator DAX: Программирование 7 14.12.2004 14:48
Говорят вышел SP2 для Axapta 3. Кто нибуть что знает на эту тему? soin DAX: Прочие вопросы 10 13.10.2003 10:43

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:30.