EffectiveDateTime на view с outerJoin

[kitty]

Есть MyView.
Оно основано на запросе со следующей структурой
VendTable
->(outerJoin 1:1)DirPartyPostalAddressView
->(outerJoin 1:1)ContactPerson
...
etc.

Проблема:
DirPartyPostalAddressView имеет validFrom & validTo, и также validTimeStampEnabled = yes, но пока я на моем "внешнем" MyView не поставлю validTimeStampEnabled = yes, выбираются все адреса, не зависимо от текущей даты.
Поэтому, чтобы выбирался коррктный адрес, приходится ставить validTimeStampEnabled = yes на моем внешнем view
Так как связь по outerJoin , то, те поставщики, у которых нет адреса, сразу пропадают из выборки, тк условие наклыдвается на все MyView, что мне не нужно

Как это обойти?

AX20121R3

[wojzeh]

а что нужно-то получить в итоге? в чём, так сказать, ТЗ?

[kitty]

Нужна элементарная вещь - информация о поставщиках:
Поставщик1 - Адрес текущий - контактное лицо такое-то
Поставщик2 - (нет адреса) - контактное лицо такое-то

А получается:

либо (когда validTimeStampEnabled = no на внешнем view)::
Поставщик1 - Адрес старый - контактное лицо такое-то
Поставщик1 - Адрес текущий - контактное лицо такое-то
Поставщик2 - (нет адреса) - контактное лицо такое-то

либо (когда validTimeStampEnabled = yes на внешнем view):
Поставщик1 - Адрес текущий - контактное лицо такое-то

Установка validTimeStampEnabled = yes на внутреннем view влияния не оказывает. А нужно ограничить именно внутреннюю выборку, то есть адреса по дате. А поставщиков же показывать не зависимо от того, есть у них в принципе адрес или нет

[kitty]

Уже даже пробовала даже сделать промежуточный view:
View внутренний ( validTimeStampEnabled = yes): vendTable inner join DirPartyPostalAddressView.
View внешний( validTimeStampEnabled = No): vendTable outer join "View внутренний" по vendTable.AccountNum

результат то же, то есть фильтр по дате на адреса в "View внешний" не накладываются

Видимо, ядро умеет накладывать фильтр по дате только целиком на весь запрос, то есть, результитрующий View А "по-умному" на его внутренние подзапросы не умеет, хоть внутренний подзапрос - сам по себе view c validTimeStampEnabled = yes

[wojzeh]

можно сделать первую вьюху с текущими адресами

либо (когда validTimeStampEnabled = yes на внешнем view):
Поставщик1 - Адрес текущий

а уже из него выбирать outer join во второй, где будут и контактные лица.

так работает?

[kitty]

Извините, я либо не поняла Вашу идею, либо Вы говорите о том варианте, что я описала постом выше, когда пыталась внутренний view только ограничить. Этот вариант не работает

Попробую описать проблему еще раз:
У меня не все поставщики имеют адреса. Если я накладываю validTimeStampEnabled = yes на внешний view (у которого структура: VendTable-> outerjoin "DirPartyPostalAddressView"), то поставщики без адреса не выводятся. Но зато адрес выводится корректно у тех, у кого он есть, то есть, только актуальный адрес.
А если я оставляю validTimeStampEnabled = yes только на внутреннем DirPartyPostalAddressView, то эффект получается такой , будто вообще ограничеения по дате не накладываются. То есть, выводятся все поставщики( что хорошо), но вот
все их соответствующие адреса уже без фильтра по дате (что плохо).

[wojzeh]

1. view1: vendAcc; vendAddr (только актуальные существующие адреса)
2. view2: vendAcc; contact; + outerJoin to view1.

так-то можно сделать?

[S.Kuskov]

Дело в том, что validTimeStampEnabled = yes не добавляет в текст View желаемого фильтра по датам. Это свойство лишь протаскивает поля validFrom & validTo наружу View и сообщает ядру что с этим View нужно работать также как и с таблицей у которой включён validTimeStamp. При необходимости из такого View можно достать не только актуальные данные но и исторические. Также как и из оригинальной таблицы. Фильтрация по текущей дате добавляется ядром на последнем этапе, когда формируется уже запрос к самому View.
Не поможет также и попытка внедрить в текст View макро функции типа SysQueryRangeUtil ValidTimeState for views' queries

Для похожей задачи я использовал следующее допущение. Я предположил, что в моей validTimeStamp таблице не будет данных заведённых будущим числом и не будет безальтернативно закрытых позиций (когда validTo предыдущей записи закрыт прошедшей датой, а новая запись с актуальным validFrom отсутствует). Тогда актуальная строка, если она есть, будет иметь максимальный validFrom среди других строк относящихся к тому же ключу. Остаётся выбрать отдельным View максимальные значения и соединением с этим View отсечь все остальные. Вуаля, остались только актуальные записи! Максимальное значение выбирал через группировку и агрегатную функцию

[kitty]

Спасибо. Видимо, действительно единиственный вариант - через агрегацию
Или, может, union еще можно попробовать (отдельно добавить тех, у кого адресов нет)