Мне кажется, проблема скорее с запросом, чем с шаблоном. Вроде типовой LEFT OUTER JOIN получается, но у Вас отчетное средство "left outer" забыло )))

Получилось вывести данные корректно, если в шаблоне в табличной части вывода сделать две строки - первую для UNICA_BINs, вторую для записей SIEBEL_DATA. Некое дерево получается. Но выглядит уродски, хотелось бы все в одной строке сделать.

Тут скорее нужно в форум XML/XSLT обращаться, можно ли на XPath изобразить union двух поддеревьев (не знаю, как это назвать). Выражение, которое указывается в for-each это просто Xpath.

Если удалось изобразить работающий шаблон (я так понимаю, в первом цикле нужно было еще if по count(SIEBEL_DATA)=0 проверять) - то лично я бы так и оставил.

p.s. по xpath union в гугле нашлось:

Где-то в инетеUnion (|) Operator

XML Path Language (XPath) supports the set operation |. The |, or union, operator returns the union of its two operands, which must be node-sets. For example, //company | //employee returns a node-set that combines all the //company nodes and all the //employee nodes. Multiple union operators can be chained together to combine multiple node-sets. For example, //company | //employee | //sales | //consultant returns a node-set containing all //company , //employee , //sales , and //consultant elements. The union operator preserves document order and does not return duplicates.

Такое нужно? Почему все такие безрукие (((

note: деньги на пиво перечислять Санкт-Петербург, бар Твин-Пикс, Лиговский просп., 9/31
note2: первая строчка может дублироваться, т.к. придет и с UNICA_BINS и с SIEBEL_DATA, поэтому из SIEBEL_DATA ее нужно выкидывать.
note3: Так же фигня с адресацией UNICA_BINS внутри цикла, т.к. при обработке SIEBEL_DATA нужно добавлять две точки. Если имена полей между таблицами не совпадают, то проще тем же самым union сделать по методу "первый попавшийся". Если имена полей могут совпадать, то тогда нужно if'ами, т.к. может быть ошибка "первый попавшийся, не попал". Но if'ами скорее всего будет намного больше букв, т.ч. лучше имена делать уникальными.

IMHO

2.xml



2.rtf<?for-each: UNICA_BINS | SIEBEL_DATA[position()>1]?>
UNICA_BINS=<?BIN1 | ../BIN1?> <?CAMPAIGN_DATE | ../CAMPAIGN_DATE?>
SIEBEL_DATA =<?COMPANY_NAME?>
<?end for-each?>


outputUNICA_BINS=9999999999 01.01.2020
SIEBEL_DATA =
UNICA_BINS=0000000000 22.09.2020
SIEBEL_DATA =Рога и Копыта
UNICA_BINS=0000000000 22.09.2020
SIEBEL_DATA =Копыта и Рога

Цикл можно заменить на:

<?for-each: SIEBEL_DATA | UNICA_BINS[count(SIEBEL_DATA)=0]?>

или на два цикла

<?for-each: UNICA_BINS?>
<?for-each: SIEBEL_DATA | parent::UNICA_BINS[count(SIEBEL_DATA)=0]?>

с последним не очень уверен, плохо знаю XPath (((

ну в общем, вариантов много, нужно тестировать

стоп стоп.
В 22201928 у меня все выводится.

Проблема в том, что получается "мешанина" из SIEBEL_DATA и UNICA_BINS

данные BIN1 и CAMPAIGN_DATE в этом случае есть, но их положение совершенно разное. Для "итерации" которыя запустилась по SIEBEL_DATA нужно обращаться как
../CAMPAIGN_DATE
а для "итерации" которая запустилась по UNICA_BINS просто
CAMPAIGN_DATE

Тут или нужно сложный XPath для for-each придумывать (но это нужно в профильный подфорум, я XPath настолько хорошо не знаю) или разводить IF'ами или брать оба варианта и дальше "первое попавшиеся"

<?../CAMPAIGN_DATE | CAMPAIGN_DATE?>



Вы же так и сказали. Пойди в самый верх документа, потом ниже....пока не найдешь значение по такому пути. В документе таких значений масса - возврашается самое первое.

Поскольку путь абсолютный, то на for-each он банально не обращает внимание.

IMHO могу ошибаться. Документацию читал давно. С XML Publisher плотно работал лет 10 назад. Терминологию и детали уже не помню.

Ну и повторю IMHO

Обрабатывать данные в XML Publisher это тупиковый путь. Простейшую обработку сделать можно, все же XSLT и XPath имеют достаточно возможностей. Но увлекаться не стоит:
1. требуются продвинутые знания XML/XSLT/Xpath и пр
2. требуется опыт
3. тестирование сложнее, чем тестирование SELECT'ов
4. с учетом 1-3 как такой отчет потом сопровождать - не очень понятно

Все же, если есть возможность, лучше данные формировать в удобном виде на стороне сервера.

Когда мы рисовали отчеты, мы часто даже даты / числа в текст перегоняли на стороне SQL Server'а. Т.к. даже заниматься форматированием вывода чисел на стороне XML Publisher'а - можно, но все же более сложно, чем привычными SELECT'ами, TO_CHAR'ами

AFAIK & IMHO