НадеждаМНет бы сразу посмотреть и сказать вот там и там не верно.
Считается, что в таких случаях программист виноват.
Нужно тестировать все. В моем случае - просто строку в коде не в том месте написал. Невнимательность + не все тесты провел. Да и человека жалко - со штрихом 3 часа сидеть...

НадеждаМВинова то виноват, но сами косяков навводят, а я потом разбирайся.

Да да, это тоже бывает, согласен.
Программист тут максимум, что может сделать - проверки навешать.
Но все не проверишь.
НадеждаМОчень много ошибок в данных при вводе делают...руки бы им оторвать.
Руки отрывать не нужно.
Можно отчеты сделать по нессответсвиям и расхождениям по особо важным данным (на Crystal'е ).

НадеждаМДа отчетов куча, смотри где не соответсвует, нет же бегают с выпученными глазами O_O.
У меня немало пользователей. Со всеми хорошие отношения.
Были у меня косяки, но на меня не обижались, а я старался исправлятся.
Я всегда расстраиваюсь, когда по моей вине где-то сбой в программе.
А пользователи меня все успокаивают - "не ошибается тот, кто ничего не делает".
По своему опыту - больше все-таки моих ошибок в программе, чем их ошибок ввода.
Ну ладно, это уже оффтоп, успехов вам с отчетами.

НадеждаМПопробовала пример, с табличкой pay_tab все нормально вроде, а вот с табличкой pay_tab_old где дублируются даты, тоже вроде порядок расположения данных как надо, а даты оплаты повторяются всеж таки, а не должны.
Надежда,
pay_tab - это данные, которые должны быть созданы хранимкой, для правильного формирования отчета.
pay_tab_old - это те, которые у вас сейчас формируются (old - старый вариант).
Я для сравнения вам оставил, чтобы вы поняли, что у вас не так.
У вас сейчас хранимка делает лишние данные, которые вас и беспокоят.
Т.е. в дублированных данных с датой оплатой виновата хранимка, а не кристал.
И всего делов-то, а вы в Crystal'е ошибки ищите.
Кстати посмотрите как я секции и группировки настроил, поразбирайтесь почему я по-другому сделал.

НадеждаМЯ уже везде ищу ошибки не только в crysal. Не могу я просто эти даты никуда деть, вот и получается ерунда когда больше одного человека.
Надежда, ну не знаю как вам объяснит-то...
В должны были в хранимке выдать группу №1 с людьми, потом группу №2 с датой оплаты.
Количество записей там должно быть столько, сколько у вас должно быть в отчете на экране.[b] Хранимка выдает [b]больше (повторяюсь). Поэтому у вас и лишку выдается.
Вы не должны union'ом объединять 2 одинаковых запроса, вы должны union'ом объединить два разных запроса, возвращающие нужное количество записей для каждой группы.
Вот решение проблемы.

MAYAKOV_SVВот решение проблемы.
Т.е. нужно исправить хранимую процедуру.

НадеждаМ,

Еще - если вы для первой группы суммы выставите в хранимке нулевые, а для второй реальные, тогда общий итог просто считается. Ну это другая песня.

НадеждаМВобще с ума схожу с этими суммами в этом отчете.
Надежда, не теряйте надежды, я верю, что все у вас получится.
С дублированными датами проблема решилась? Запрос в хранимой процедуре выдает только нужный набор записей?

MAYAKOV_SVС дублированными датами проблема решилась? Запрос в хранимой процедуре выдает только нужный набор записей?
Это я к тому, что странное для меня поле indcnt в расчетах, в данном случае, не нужно.
1) Если вы в GroupID = 1 payment сделали равным нулю, то stritog получем:
Суммируем все - первая группа не нужна, но там нули, а суммируем недублированные записи из второй группы и получаем общий итог.
2) Если в GroupID = 1 payment не ноль, то нужно помучится вычесть эти данные из группы.
Эх, незнаю синтаксис агрегатных функций в Crystal.
Чисто случайно набил:
Вроде показывает так, как надо. Но не факт, что эта формула правильная.

Первый вариант мне нравится больше, т.к. он более и логичный.
Сделать его просто.
В хранимке поправить (смотрю старый ваш вариант):
Вам дали хороший совет по поводу дублирования данных, но вы не довели мысль до конца, поэтому у вас возникают проблемы.

PS. Чем проще отчет, тем лучше.

Этот вариант:
Работает так:
GROUPIFIOPAYMENTFIOZ1Даша0Даша1Даша0Саша1Даша0Вера2Даша100Даша2Даша50Саша2Даша200Вера
Итог = 350
Суммируется так: (0 + 0 + 0 + 100 + 50 + 200).

НадеждаМи почему-то не хватает 2-х полей...хотя в этой хранимой процедуре на сервере они точно присутствуют и при выполнении в результате запроса точно есть.

Verify Database нужно запустить для того, чтобы привести в соответствие.
Я гляжу там не только двух полей нет, но по одному полю различие: name<>names.