Hi Hank,

The client I am doing this for has a mix of VFP, VB and ASP/Web applications. They have an ASP page that calls all the crystal reports. Everything is data driven, and they want it to conform to their standards. They are trying to move everything here to ASP and eventually to .net. Regrettably, they reject any new VFP based solutions that I propose - even VFP COM objects. They tell me that if I create a VFP based solution the other developers won't know how to maintain it.

Your implementation sounds pretty cool, but, as per the above, I don't think this client would go for it. But I'd like to consider it for other applications/clients where I don't have these constraints.

Thanks again for your help!



>Hi David,
>
>in our crystal class, we create a temporary DBC which takes whatever cursors we have, and creates a temporary DBC with the cursor inside. The cursor name, and the name of the cursor as referenced in the report (and the subreports) is contained in the data fed to the wrapper; and the datasources for the report, and the subreports, are changed to the dbc/table by the wrapper that shows/prints the report.
>
>So all we do is figure out where the data is coming from and what name it is; and then run the routine, which creates the temp dbc (in development mode it creates it in our app reports\data directory), and then design the report (and subreports) against the data in the temp dbc.
>
>Frank Camp designed the system, and it really saves a lot of work. The amount of time to create the temp dbc is nothing compared to the printing of the report; besides, this is something VFP is good at. <s>
>
>Hank
>
>>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.