Связывание источников данных в запросах

[r25]

Прошу знающих людей объяснить, как происходит связывание источников данных в отчетах, то есть в чем различие между связыванием одного источника к одному источнику и одного к нескольким на последующем уровне - не работает так как нужно . Вообще какие есть ограничения при построении дерева источников данных - Ахсапта компилирует и запускает практически любую комбинацию но выбирает данные не верно. Чем управляет "таинственное" свойство источников данных FetchMode (так и не понял ни из документации ни из предыдущих сообщений в форум). Заране большое спасибо!

[vanokh]

Может за 7 лет кто-нибудь выяснил в подробностях, какой именно "физический" смысл имеет FetchMode? Где его нужно и не нужно ставить (вид джойна, узел или лист в иерархии датасорсов)?

[TasmanianDevil]

Цитата:

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

Может за 7 лет кто-нибудь выяснил в подробностях, какой именно "физический" смысл имеет FetchMode? Где его нужно и не нужно ставить (вид джойна, узел или лист в иерархии датасорсов)?

Если на узел вешаете несколько листов (например запрос по InventTrans c при-join'ными InventTable и InventDim) - листам надо указывать. В противном случае, система, не зная, какие отношения между таблицами существуют, при попытке добавить второй лист сбросит первый - что прекрасно видно в дебаггере при трассировке.

[kashperuk]

Цитата:

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

Если на узел вешаете несколько листов (например запрос по InventTrans c при-join'ными InventTable и InventDim) - листам надо указывать. В противном случае, система, не зная, какие отношения между таблицами существуют, при попытке добавить второй лист сбросит первый - что прекрасно видно в дебаггере при трассировке.

Ну, это не совсем так.
Система, ессно, знает, какие отношения существуют между таблицами, и может по ним построить правильный запрос. Просто значение по умолчанию для FetchMode = Один ко Многим.
Поэтому вместо одного запроса выполняется несколько независимых:
Один - InventTrans->InventTable
Второй - InventTrans->InventDim

а потом все 3 курсора заполняются соответствующими данными.

Поэтому в дебаггере видно, как будно один источник "отпал".

Если же посмотреть, какие запросы при этом выполнит SQL, то должны увидеть оба запроса.

Я все собираюсь написать блог пост tutorial с примерами, но не хватает времени.

[kitty]

2 kashperuk: Эта статья про FetchMode на axaptapedia находится(не нахожу там) или в каком-то другом блоге?

[kashperuk]

Все зависит от того, какой вам нужно получить запрос в результате?
Если вам нужен запрос с join, как вы бы написали в SQL, то ВСЕГДА используйте FetchMode равный One2One.
Если же вам нужно другое поведение, когда данные из связанных таблиц выбираются отдельно, и у вас есть код, который завязан на смену записи в конкретных таблицах, то используйте 1ToN

Мой общий совет - всегда используйте 1-To-1

[vanokh]

Ага, многое прояснилось.
Про смену записи в конкретных датасорсах я догадался
Еще вопрос - допустим у нас есть запрос с несколькими Exists Join'ами. В этом случае для основного источника все они вернут по одной записи. На практике я столкнулся с тем, что основной запрос с учетом фильтра по джойнам выбирает одну запись, а next() в Query проходит аж 30 раз (Exists Join'ов присоединено 6-7 штук). Спасает One2One или контроль changed() на основном запросе. Но так и осталось загадкой почему все-таки 30 раз...

[kashperuk]

К сожалению, так и не написана, в виде разных маленьких заметок у меня на диске.