Since the reports are run from an application, you can have the application push the data (the application gets the parameters from the user, retrieves the data, and sets the datasource of the report, and then displays the report in a Crystal Report viewer)
Or you can call the Crystal Report viewer, set the report and let the user set the parameters and retrieve the data
Or you can have the application set the parameters in the report, and display the result in Crystal Report viewer
There are probably a few more, but those are the ones that I have used. My favorite, is the first:
1) You don't need to worry about setting up a connection from Crystal to the database, so if you have multiple databases to attach to or you want to give your users the ability to switch between production and test environments the connection issue is moot, as long as your application handles it correctly.
2) you don't need to use Crystal's parameter screen, which I don't consider the most user friendly (we have created Wizards to step the user through the parameter selection)
3) if you would like to post process the results from the database, you can before sending them to Crystal
4) should you decide to leave Crystal and move to another reporting platform, there is less coding as the report parameters and data retrieval are removed from the report (or you can support multiple reporting platforms...my company is currently supporting legacy Crystal and a newer reporting system from DevExpress. Both use the same wizard / base class)
Hope this give some ideas. The first solution requires the most coding (as the application is doing most of the work), the second the least(all the application does is call the report, the report does most of the work) and the last has a middling amount of coding as both the application and the report are doing a piece of the work)
IP Logged
