Для решения каких задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[belugin]

Цитата:

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

одновременно на одном датасорсе то когда они требуются?

Как раз в том сообщении, на которое ты отвечаешь, я привел пример.

[mazzy]

Цитата:

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

Как раз в том сообщении, на которое ты отвечаешь, я привел пример.

Нет там примера где dynalink и link требуются ОДНОВРЕМЕННО на одном датасорсе.

Цитата:

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

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

внешняя форма
└датасорс: номенклатура

спецформа
└датасорс: строки инвойсов (dynalink: номенклатура)
 └датасорс: шапки инвойсов (link: строки инвойсов)

Легко видеть, что dynalink и link на разных датасорсах.

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

напомню свой вопрос полностью:

Цитата:

Для решения каких задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[belugin]

спецформа
└датасорс: строки инвойсов (dynalink: номенклатура)
 └датасорс: шапки инвойсов (link: строки инвойсов)

> Легко видеть, что dynalink и link на разных датасорсах.

Ок. Пусть так.

Теперь нам надо использовать эту удобную форму но вызывать ее из формы поставщиков. Мы в init добавляем addDynalink на шапки инвойсов и шапки линкуются к строкам через линк а к поставщикам через дайналинк.

[mazzy]

Цитата:

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

но вызывать ее из формы поставщиков.

в этом случае запрос будет выглядеть так:

внешняя форма
└датасорс: поставщики

спецформа
└датасорс: шапки инвойсов (dynalink: поставщики)
 └датасорс: строки инвойсов (link: шапки инвойсов)

наверное, я плохо выделил слово ОДНОВРЕМЕННО.
повторяю исходный вопрос:

Цитата:

Для решения каких задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[belugin]

Цитата:

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

в этом случае запрос будет выглядеть так:

спецформа
└датасорс: шапки инвойсов (dynalink: строки поставщики)
 └датасорс: строки инвойсов (link: шапки инвойсов)

За счёт чего в в той же самой форме поменяется порядок источников данных для вызова из другого места?

Цитата:

и я плохо выделил слово ОДНОВРЕМЕННО?

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

[mazzy]

Цитата:

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

За счёт чего в в той же самой форме поменяется порядок источников данных для вызова из другого места?

по-нормальному, тот же программист-орел, что добавляет dynalink на внутренние датасорсы.

Цитата:

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

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

Пля...

Я накидал макетик на ax2012 и ax2009.

получается, что диналинк можно добавить вручную в коде на внутреннюю таблицу. и он даже будет работать. см. приложенный проект и скриншоты с одновременным существованием ветки dynalink и relation.

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

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

ок, согласен, что исходный вопрос нужно уточнить: Для решения каких бизнес-задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[mazzy]

Цитата:

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

Я накидал макетик на ax2012 и ax2009.

Уточнил макетик.

Раньше я лихо использовал innnerJoin между датасорсами спец-формы.
Одумался и сделал вариант с DelayedJoin.

Конечно же в варианте в delayed join нет одновременного dynalink и link.
Конечно же в варианте в delayed join работает совсем не так как ожидает пользователь - фильтрует только внутреннюю таблицу, а шапки оставляет нетронутыми.

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