join-ы

[Antonuch]

Доброго всем времени суток. Просьба помочь разобраться с отчетом. Есть три таблицы (InventSum состояние склада, InventTable картотека номенклатуры, ConfigChoice выбор нн в зависимости от конфигурации оборудования.) Схема данных в файле. Данные выводятся на грид из InventSum как добиться того, чтобы в отдельном поле формы были нн деталей (которые в зависимости от сопоставлений с ConfigChoice выхватывались бы из InventTable), если это комплект (соответственно нн всего комплекта повторялся бы) Заранее благодарю.
сорри за банальность

[EVGL]

Вчера был задан вопрос, как написать join. Сегодня, как и ожидалось, - второй шаг: join написан, как сделать так, чтобы он выдавал то, что хочется?

Скучно. И не хватает связки с ConfigId через InventDim.

[Antonuch]

))) EVGL да вы юморист, сударь, тот join, что был написан вчера не работает, к сожалению, пришлось мне кое-что переосмыслить, теперь заново бьюсь

[EVGL]

InventSum.InventDimId -> InventDim.ConfigId == ConfigChoice.ConfigId AND
InventSum.ItemId == ConfigChoice.ItemId

Таблицы, подобные ConfigTable, довольно неприятные. Связка получается по двум путям разной длины:

InventSum -> InventDim -> ConfigTable
InventSum -> ConfigTable

Такой запрос для формы построить нельзя. Остаются варианты типа временных таблиц или шатких предположений, что идентификаторы конфигураций уникальны.

[Antonuch]

Был бы сам рад, да в InventDim поле ConfigID пустое, и заполняться не планирует
нужен курсор по InventSum чтобы в случае комплекта нн в форме разбивалась на несколько строк подетально ( апривязка по комплектам только через СС.ItemId->CC.ChosenItemID

[blokva]

Цитата:

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

Был бы сам рад, да в InventDim поле ConfigID пустое, и заполняться не планирует
нужен курсор по InventSum чтобы в случае комплекта нн в форме разбивалась на несколько строк подетально ( апривязка по комплектам только через СС.ItemId->CC.ChosenItemID

Я что то наверное не понимаю, Вы что переделали функционал конфигурирования? Если нет, то без InventDim не обойтись...

[belugin]

Цитата:

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

Такой запрос для формы построить нельзя.

Точно?

А если так

InventSum -> InventDim --> ConfigTable

ConfigTable.addRange(fieldNum(ConfigTable, RecID, '(ConfigTable.ItemId==InventSum.ItemID)');

[belugin]

Вот так прокатывает, а если заменить на Outer, то нет

static void Test3Tables(Args _args)
{
    QueryRun qr =
        SYS_ExpressionQueryBuilder::addDataSource(tableNum(InventSum), 'InventSum')
            .join(tableNum(InventDim))
            .link(fieldNum(InventSum, InventDimID), 
                  fieldNum(InventDim, InventDimID))
            .join(tableNum(ConfigTable), 'ConfigTable')
                .link(fieldNum(InventDim, ConfigId),
                      fieldNum(ConfigTable, ConfigId))
            .matches(fieldNum(ConfigTable, RecID), '(ConfigTable.ItemId==InventSum.ItemID)')
            .run();
    ;
    qr.next();
}

[belugin]

Невозможно выбрать запись в 'Таблица конфигурации' ('ConfigTable')
Использован оператор объединения таблиц join, но выражение WHERE не содержит связи между таблицами.

static void Test3Tables(Args _args)
{
    QueryRun qr =
        SYS_ExpressionQueryBuilder::addDataSource(tableNum(InventSum), 'InventSum')
            .join(tableNum(InventDim))
            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))
            .outerJoin(tableNum(ConfigTable), 'ConfigTable')
                .link(fieldNum(InventDim, ConfigId),
                      fieldNum(ConfigTable, ConfigId))
            .matches(fieldNum(ConfigTable, RecID), '(ConfigTable.ItemId==InventSum.ItemID)')
            .run();
    ;
    qr.next();
}

[glibs]

По-моему, на картине изображена ненормализованная структура данных, раз связи замкнулись в кольцо. Вообще не удивлюсь, если такой запрос нельзя написать на SQL в принципе (одним запросом).

Тем не менее, Antonuch, вы работаете со стандартной функциональностью или с авторской?

[belugin]

мне в-общем не очень понятно, как присоединяется ConfigChoice, по inner join или по outer, но может попробовать innerJoin во view запихать?

Может напишете запрос на обычном SQL а мы его попробуем транслировать?

[EVGL]

Цитата:

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

Невозможно выбрать запись в 'Таблица конфигурации' ('ConfigTable')
Использован оператор объединения таблиц join, но выражение WHERE не содержит связи между таблицами.

static void Test3Tables(Args _args)
{
    QueryRun qr =
        SYS_ExpressionQueryBuilder::addDataSource(tableNum(InventSum), 'InventSum')
            .join(tableNum(InventDim))
            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))
            .outerJoin(tableNum(ConfigTable), 'ConfigTable')
                .link(fieldNum(InventDim, ConfigId),
                      fieldNum(ConfigTable, ConfigId))
            .matches(fieldNum(ConfigTable, RecID), '(ConfigTable.ItemId==InventSum.ItemID)')
            .run();
    ;
    qr.next();
}

Встретился с фирменным стилем belugin в классе CustVendPaymERExport. Кратко, изящно, все нужные методы private, невозможно вклиниться и расширить. Спасибо огромное, продолжайте в том же духе и мы останемся на 7.2.

[belugin]

Можно ли узнать, что именно необходимо расширить и какой код в 7.2?

См. также обсуждение некоторых изменений модуля в 7.3

[Logger]

Цитата:

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

Можно ли узнать, что именно необходимо расширить и какой код в 7.2?

Максим, а вот такое выражение

            .link(fieldNum(InventSum, InventDimID),
                  fieldNum(InventDim, InventDimID))

можно заменить чем то типа

            .linkRelation('\Data Dictionary\Tables\InventSum\Relations\InventDim')

?

Так бы лучше инкапсуляция была и можно было бы проверку от опечаток сделать внутри вызова linkRelation(). Тогда не было бы ситуации когда в имени таблицы или поля опечатался и запрос работает, но неправильно.

[EVGL]

Изменили режим, в котором создаются строки платежей, с "много дебет-кредит" на "много дебетов - один кредит", но указанный класс всегда фильтрует по Offset account, которого нет, и и который на самом деле не требуется для создания файла. Вклиниться в query невозможно, изменить класс context - невозможно, поскольку он в одной строке и создается, и передается в итоговый класс. По уму надо было разбить на несколько методов, создать hooks.

P.S. В конечном итоге, нашел с программистом вариант, как сломать через extensions. Много позже в ходе исполнения отловить query и сделать .clearLinks() если попадается таблица LedgerJournalTrans. Ненадежно, опасно, трудно отлаживать, может вылезти в неожиданном месте при попытке создать новый электронный отчет, зато Microsoft доволен. Вполне себе типичное решение через extensions, где делается предположение о внутренней структуре, а после нас - хоть потоп.

[belugin]

Цитата:

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

            .linkRelation('\Data Dictionary\Tables\InventSum\Relations\InventDim')

Так бы лучше инкапсуляция была и можно было бы проверку от опечаток сделать внутри вызова linkRelation(). Тогда не было бы ситуации когда в имени таблицы или поля опечатался и запрос работает, но неправильно.

Теоретически я бы делал так:

.linkRelation(tableStr(InventSum), relationStr(InventSum, InventDim))

Но у нас нет relationStr так, что если кто-то переименует relation, мы узнаем только в runtime. Если вы пишете тесты, то это небольшое неудобство, но если нет, вам могут сломать код, а узнает об этом только пользователь.

[Logger]

Цитата:

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

Но у нас нет relationStr так, что если кто-то переименует relation, мы узнаем только в runtime.

Это намного лучше, чем если отработает, но не с теми полями. Уж лучше пусть ошибка в рантайм.

[belugin]

Цитата:

Насколько я понял, смысл кода в том, чтобы, если внутри журнала есть платежи относящиеся к нескольким счетам компании, а пользователь выбрал один, то надо вывести в файл только платежи отнсящиесиеся к заданному счету.

То есть в вашем случае надо либо передать backAccountID == '' (там есть обработка этого случая) либо обеспечить корректную филтрацию, вычисляя OffsetAccount по ваучеру. Либо каким-то образом запретить создание платежей по нескольким банковским счетам компании (насколько я помню этот функционал).

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

P.S. Ой, извините, я - EVGL - по ошибке отредактировал ваш текст. Надо отнять у меня права модератора, что-ли?

[Pustik]

В конечном итоге, нашел с программистом вариант, как сломать через extensions, не дай бог

[Pustik]

кошмар