Hiya Guys,
I have a report which uses an SQL Stored Procedure as it's datasource (with parameters - as research suggests this improves performance).
Research also suggests that all parameters passed are in String format (type-conversion performed in SP).
This means that entering dates/multiple values/etc. is difficult for the end-user (as, for example, they are required to manually enter a date as "20120404" rather than being able to use the Calendar Picker/Date-Range functionality).
Research suggests that it is possible to get around this problem by embedding the SP report as a Subreport, and then linking the SP parameters to Formula Fields which are handled by the Main Report (meaning lists/date values/etc. can be generated and formatted before passing to the SP).
ISSUE:
As soon as I add a "Link" between my Main and Subreport - the Subreport REFUSES to generate (as, I believe, this is done during the "WhilePrintingRecords" - as if I drill-down into the Subreport it displays correctly!).
I have tried:
1) Declaring a SHARED variable in the Subreport Footer (and everywhere else!) which calculates a GrandTotal - then passing it to the Main Report within a Formula Field (both fields are NOT suppressed). This should force the records to be printed so the variable can be calculated? Doesn't help. I get "0" for the result (and still no Subreport);
2) Adding a datasource to the Main Report and displaying a Data Field (to force database access). Doesn't work. The datasource is accessing the same database, but NOT the same SP (as it would ask for parameters - and therefore put me in the same situation!);
Has anyone ever come across this (
incredibly ridiculous) limitation within Crystal? I thought I was making progress (and all online documentation appears to point at this solution) -
so what am I doing wrong?! 
If anyone has any input it would be greatly appreciated!
Cheers,
Steve.
Edited by bainsteven - 04 Apr 2012 at 12:42am