OK, in most of the Crystal applications I built, each report was tied to a stored procedure. So in one example, a single report called a single stored procedure, where the procedure might bring back 1 or more result sets (maybe a summary/detail scenario).

I created a strongly-typed instance of the report in the .NET project, and also used strongly-typed datasets as a model of the result sets. At runtime I'd execute the stored procedure, return the results into typed datasets and then "push" the typed dataset into the report The structure/columns in the typed dataset reflected what the report expected when I built it in design time to begin with.

Now, at the center of everything was a library where I could invoke the many Crystal functions. Several years ago I wrote an article in CoDe Magazine on such a library (it's actually from a Crystal reports book I wrote just prior to that).

The article (and code) can be found here. Listing 1 is the library I created that taps into the Crystal API.
http://www.codemag.com/Article/0701031

I'll give you some of the highlights of the article and library that might be of interest to you.

First, I'd create an instance of the typed dataset that the report will eventually need:

dsTimeSheets odsTimeSheets = new dsTimeSheets();

Then I'd call whatever stored procedure I needed to call, to populate the dataset with data that I'd eventually push into the report.

Next, I'd create a strongly typed instance of the report itself:

RPT_TimeSheet oTimeSheetReport = new RPT_TimeSheet();


Then I'd instantiate the custom Crystal Reports library I created: (the full source is in listing 1 of the article URL I mentioned above)

ccCrystalManager oCrystalManager = new ccCrystalManager();


Then I'd "push" the dataset into the report. Again, I'm using my custom library, which in turn taps into the crystal reports object model to set the report's table definitions at runtime:

oTimeSheetReport = oCrystalManager.PushReportData(dsData, oTimeSheetReport);


At this point, the runtime instance of the report object is ready to be previewed, or printed, or exported, using functions in the library:

// To go straight to the default printer
oCrystalManager.PrintReport(oTimeSheetReport);



oCrystalManager.ExportReport(oTimeSheetReport, "c:\\mypdf.pdf", ccCrystalManager.ExportTypes.PDF);


So I'd focus on the guts of the solution first - get a good prototype executable running with a few reports. And then you can deal with making the executable a SQL Agent job.


Let me know if that helps as a good start for you. I won't swear this will work well in every scenario, but it was the general methodology that helped pay the bills for years :)