Query

[Eldar9x]

Вот, возник такой вопрос.
1) В каком порядке будет выполнятся запрос объекта AOT Query, если у него два датасорса на одном уровне?
2) Когда лучше создавать Relation не на таблицах, а на расширенном типе данных?

[mazzy]

Цитата:

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

Вот, возник такой вопрос.
1) В каком порядке будет выполнятся запрос объекта AOT Query, если у него два датасорса на одном уровне?

См. Руководство разработчика. Раздел по ключевому слову "Sequencing of retrieved records".
См. также Глюки в Query с разными типами Join (в т.ч. NonExistsJoin) к одной таблице

Цитата:

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

2) Когда лучше создавать Relation не на таблицах, а на расширенном типе данных?

Relation лучше создавать на таблицах, Когда:
1. relation по сути своей устанавливается по нескольким полям ОДНОВРЕМЕННО.
2. Если допускается вводить значение, отсутствующее в main table (такое бывает очень редко)

Если есть возможность, то лучше использовать relation на типах.

[kashperuk]

ИМХО:

1. Сверху вниз. Сначала первый, потом второй. Об этом упоминается где-то в DevGuide
2. Когда этот расширенный тип будет привязан к какой-то таблице постоянно. То есть используется всегда как вторичный ключ.

[mazzy]

Цитата:

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

2. Когда этот расширенный тип будет привязан к какой-то таблице постоянно. То есть используется всегда как вторичный ключ.

?!
Можно пояснить?

[kashperuk]

Ну, криво изъясняюсь.
Имеется ввиду, к примеру, EDT ItemId - всегда служит ссылкой на таблицу InventTable

Это называется вторичным ключем, если не ошибаюсь. (в тех таблицах, которые соединяем с InventTable)

[mazzy]

Цитата:

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

EDT...

Упс...
Я неправильно ответил. Щас поправлю.
Спасибо.

[Eldar9x]

спасибо за ответы, очень пригодится

[kashperuk]

Цитата:

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

1. relation по сути своей устанавливается по нескольким полям ОДНОВРЕМЕННО.

По этому пример, кстати, на строках журналов LedgerJournalTrans
Очень красиво и без кода работает переход к основной таблице по полю AccountNum