Crystal Reports 9 and SQL

[joaofroes]

I´m beginner in Crystal Reports 9. I´d like to know if is possible to pass a sql parameter, in runtime, to a report like in the others versions.

Thank you.

 

[bduke]

If you are referring to older versions of Crystal - I don't think so, because there are changes in Crystal 9.

 

[FVTrainer]

I'm not sure what bduke is refering to...CR 9 behaves pretty much the same as the last few versions in that regard. But, when you talk about passing a parameter value at runtime, how are you deploying the report? From within Crystal Designer? From a web app using the RDC or RAS/CE? From a vb app using the RDC? Your question's a little short on specifics if you are looking for a specific answer.

 

[joaofroes]

I´d like to pass a sql statement at runtime to a report, within a vb app, using the RDC. Using the CR 8, I used to pass a sql statement through the property .SqlQuery. And now?

 

[FVTrainer]

Well, you can still use the crRpt.SQLQueryString
method to pass a query string. But, if you are going to the trouble to create an entire query string (rather than just setting the WHERE clause via an entry to the Report.RecordSelectionFormula property), I would recommend a different approach (also, assuming you are building a report from scratch for your app rather than using one that already exists).

I would build the report using an ADO datasource. With an ADO datasource, at design time, you create a sql statement that provides the fields your report will use. At runtime, you create an ADO recordset in your vb app that contains the same exact field list (where it gets that data is completely up to you; the field list simply has to be identical in terms of the number, order, names, and data types of the fields used during design time; in short, the schemas have to identical). Once you have the recordset, you pass it to your report. It removes connectivity from the report entirely, which eliminates troubleshooting why your report can't connect to the database. And, should you need to get your data from a different database at some time in the future, you handle that in your code rather than in your report (it shouldn't require a recompile of your vb app if you write it to use an INI file or registry setting to store connection info on your source database).