![]() |
![]() |
|
Странности с отбором в СКД при наличии ДВУХ наборов данных... | ☑ | ||
---|---|---|---|---|
0
AquaKosh
01.02.10
✎
15:41
|
Приветствую, коллеги. Столкнулся с непонятным поведением СКД при наличии отбора в ОДНОМ из наборов данных (отбор СКДшный, который в {}).
Есть основная таблица (первый набор данных - факт) и вспомогательная (второй набор данных - план). Вспомогательная цепляется к основной (план к факту). 1) В самом примитивном варианте это выглядит так: --------------------------------- Товар | план | факт | --------------------------------- Мясо | 5 | 10 | Сало | 6 | 15 | --------------------------------- 2) Если, к примеру, плана нет, то выводится один факт (в плане 0). --------------------------------- Товар | план | факт | --------------------------------- Мясо | | 10 | Сало | | 15 | --------------------------------- Во вспомогательном наборе данных (ПЛАН) есть отбор по товару, при активизации которого СКД выводит пустую таблицу (шапка и сразу итог), а по идее должна выводить таблицу как в п.2, т.е. должен выводиться как минимум факт. Вся странность в том, что отбор в ПЛАН'е, заданный в запросе через параметр отрабатывает нормально, т.е. фильтруется только план, а если задать отбор в {}, то при активизации его получаю таблицу без строк. Может кто сталкивался? P.S. 1. Сделал маленький отчёт, иллюстрирующий проблему (отчёту не нужны данные из базы, они прописаны в запросах). http://slil.ru/28578325 По-умолчанию отчёт выводит всё правильно, но стоит в настройках поставить активность у отбора - пустота. 2. Два набора данных нужно обязательно. :) 3. Проблему можно обойти через задание отбора параметром в запросе, но это не есть правильный выход... 4. Платформа 8.1.15. На всякий случай пробовал на 12-ой - тоже самое. |
|||
1
IronDemon
01.02.10
✎
15:55
|
Зачем НоменклатураПлан? Поставь в условиях везде Номенклатура
|
|||
2
AquaKosh
01.02.10
✎
15:57
|
(1) Это пример. В реальном отчёте условие должно накладываться ТОЛЬКО на ПЛАН.
|
|||
3
AquaKosh
01.02.10
✎
15:58
|
(1) +(2) А "НоменклатураПлан", чтобы СКД не накладывала отбор на факт.
|
|||
4
IronDemon
01.02.10
✎
16:25
|
Я не вижу разницы в отборе номенклатуры.
|
|||
5
AquaKosh
01.02.10
✎
16:35
|
(4) Отбор по номенклатуре стоит только в план'овом наборе данных. И фильтровать этот отбор должен только план'овые данные, а этого не происходит, точнее происходит фигня какая-то - то-ли фильтруется всё, то-ли ещё что-то, но в итоге - пусто.
Получал результирующий запрос, который формирует СКД - параметр на отбор стоит только в плане (что собственно и должно быть), но СКД всё равно выводит пустую таблицу. |
|||
6
AquaKosh
01.02.10
✎
17:48
|
ап
|
|||
7
IronDemon
01.02.10
✎
17:56
|
Какой смысл отбора по Плану если левое соединение с Фактом?
|
|||
8
AquaKosh
01.02.10
✎
18:09
|
(7) Этот пример... это просто пример, имеющий мало общего с реальным отчётом.
В реальном же отчёте, конечно никакого отбора но номенклатуре нет. Пример нужен только для того, чтобы показать странность, связанную с работой отбора, которую я не могу победить настройками СКД. А в реальном отчёте плановые суммы будут меняться тоже отбором, но не по номенклатуре, а по плановым сценариям. |
|||
9
MNS_Ротерта
01.02.10
✎
18:21
|
(0) в статье по переходу на 8.2 с 8.1 на ИТС было скзано что если есть 2 связанных набора данных то если в одном из них накладывается отбор, то при связи что то там гоорилось будут добавляться дополнительные псевдо записи. ну суть в том что получишь неверный результат. может быть у тебя как раз такая ситуация?
|
|||
10
MNS_Ротерта
01.02.10
✎
18:21
|
(0) СКД вообще часто выдает интересные результаты так что не надо удивляться. Там полно глюков
|
|||
11
Garkin
01.02.10
✎
18:40
|
(5) Поправь если ошибаюсь.
Соединение наборов данных СКД делает на стороне клиента, причем сначала вытягиваются наборы данных, соединяются, а только потом накладываются отборы. Это не странность, это особенность. |
|||
12
Garkin
01.02.10
✎
18:46
|
+(11) Использовать наборы данных в СКД имеет смысл только в трех случаях:
1) При построении иерархии 2) При необходимости хитро считать итоги по группам. 3) Третьего к сожалению еще не знаю. У тебя какой? Зачем тебе 2 набора? |
|||
13
Garkin
01.02.10
✎
18:48
|
+(12) Вру, третий тоже знаю.
|
|||
14
AquaKosh
01.02.10
✎
18:48
|
(11) Не-не, дело скорее всего не в этом... В реальном отчёте отбор накладывался на виртуальную таблицу регистра и была такая же фигня...
(12) Надо хитро итоги по группа считать. |
|||
15
Garkin
01.02.10
✎
18:51
|
(14) Как ты умудряешься указать СКД на какой набор ты отбор накладываешь?
|
|||
16
AquaKosh
01.02.10
✎
18:53
|
(15) Опа! ... Хм... Что-то меня настораживает этот вопрос! :)
См. файлик (банальный отбор в {} в конкретном наборе данных). |
|||
17
IronDemon
01.02.10
✎
19:10
|
Соединение набором в СКД от лукавого. Используйте связи в обычном запросе. :)
|
|||
18
Defender aka LINN
01.02.10
✎
19:10
|
Месеье знаком с идеей левого соединения?
|
|||
19
Defender aka LINN
01.02.10
✎
19:11
|
(17) Итоги будешь вручную поправлять, когда в наборах строки дублируются? :)
|
|||
20
Garkin
01.02.10
✎
19:13
|
(16) отбор то банальный, но только непонятно из каких соображений ты делаешь вывод что он должен действовать только на один набор а не на все соединение?
|
|||
21
AquaKosh
01.02.10
✎
22:13
|
(20) Делаю вывод из здравого смысла, т.к. указываю отбор только в одном из наборов и имя отбора задаю уникальное.
Коллеги, напоминаю, что отбор, указанный вручную в запросе через параметр, к примеру Запрос.Номенклатура = "Блин", отрабатывает правильно, т.е. план по нулям и факт выводится, а такой же отбор, заданный через компоновку приводит к пустой таблице, чего быть по идее не должно. |
|||
22
AquaKosh
01.02.10
✎
22:21
|
(20) +(21) По поводу того, что якобы установленный отбор каким-то образом накладывается на другой набор данных: если-бы это было так, то задав отбор как НЕ_РАВНО я бы увидел результат, а получается, что хоть РАВНО, хоть НЕ_РАВНО - без разницы.
|
|||
23
Garkin
01.02.10
✎
23:35
|
(21) Добавь в набор данных "План" поле "ЛицоСотавившееПлан" и расскажи как сделать отбор в целом по соединению.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |