Hi Hank,

In this case I didn't want to do a subreport primarily because of the runtime. The query for this may be possibly be long-running. The subreport wants its own data source, or result set, which in this case would have to be an SP, and then, the (essentially)same sp would have to run twice. The fact that this is against sql-server data, and, in this client's environment, according to their standards, the crystal must run against an SP, makes it a little more difficult.

There have been times in the past when I have used subreports effectively in Crystal, where it is great to have them, and it is a great benefit compared with using VFP report writer. But in this case I didn't think it was the right solution, although that was the direction I was going in originally.

Hopefully this makes sense, otherwise, if you want, I will explain more as to why I didn't think a subreport would be the best way to go here.

Thanks for your input.

David


>Hi David,
>
>this is easily handled in CR using a subreport; insert a subreport to run after the details, using the same table, but grouped the way you want.
>
>Hank
>
>>Jon,
>>
>>Thanks for your suggestion! I ended up doing a trick that is commonly done with the VFP report writer, I created a detail set of rows in a temp table and a summary set, and then I appended them both into a temp table that had the columns of both and used a unique identifier for the group expression. I populated the group by expression for the values for the summary rows with 99999999, so they sorted after the detail section, which had values ranging from 1 to about 100.
>>
>>The problem in this case was that the the set of subtotals had to appear as a group AFTER the detail set of rows, not with one subtotal per group, appearing in a group footer, as I think you were suggesting. Hope that makes sense.