If you go the Crystal Report route (or whatever route for that matter), then
I'd STRONGLY suggest putting your data into a strongly typed dataset.
What I mean is that your CR should should be built on a strongly typed
dataset, and NOT talk to the database directly.
No stored procedures, no direct sql.
Now you ~can populate a dataset with a stored procedure. But make sure you
use the (strongly typed) dataset as the middle man.
Why?
Because you should view CR (or active reports, or getreportviewer.com ) as
the presentation layer. and you should NOT marry your presentation layer to
the data.
Which is exactly what you'll do if you have your CR talk directly to a
stored procedure.
By doing it this way, you can actually try different techniques.
Maybe your report can be done as a webpage as a simple <asp:repeater>
object. Maybe CR, maybe active reports.
You will have (future) choices if you do it right (seperate the data being
reported against from the presentation layer) from the get go.
Here is the basic idea at:
http://support.businessobjects.com/c...etdatasets.pdf
or even
http://scottonwriting.net/sowblog/posts/2148.aspx
"Marty" <ma********@shaw.cawrote in message
news:11**********************@h2g2000hsg.googlegro ups.com...
What is the easiest way to upgrade ms access forms and reports to
asp.net? If it means a total re-write, how do you run reports with
parameters thru an asp.net form with say date-from and date-to
parameters? Is crystal better then the built-in reports in VS 2005?
Thanks.
