When you say query.... what exactly do you mean?
Is this web or windows?
Which dotnet language?
If you're talking stored procedure and OLEDB, you use pretty much the code I posted in the post about subreport parameter problems but obviously possibly without the stuff for subreports.
I'd imagine that if it's access queries then oledb works just as well with queries but I've always used access reporting with access.
If you're using subreports with parameters I would strongly recommend you generate a datatable and set the datasource for the reportdocument to that instead of using oledb or odbc etc.
You then only have the one connection string to worry about storing for your whole application.
The data access also then uses techniques which should be familiar to a dotnet developer and reliable, minimising the scope for crystal reporting to stuff you up.
The code for generating a datatable is pretty simple, just ensure the name of your datatable matches that which the report is expecting.
You can see that in crystal if you look at the data connection for the report.
The following example is web and uses a datatable from session.
I'm assuming you can work with datatables.
============
using CrystalDecisions.CrystalReports.Engine;
public partial class RisksReport : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
ReportDocument rd;
DataTable dt = (DataTable)Session["RiskReportData"];
// Tricky bit here is to make the name of the datatable match what the report expects
dt.TableName = "DataTable1";
rd = new ReportDocument();
rd.Load(Server.MapPath("Reports\\RisksReport.rpt"));
rd.SetDataSource(dt);
rd.Refresh();
CrystalReportViewer1.ReportSource = rd;
CrystalReportViewer1.RefreshReport();
CrystalReportViewer1.DisplayGroupTree = false;
}
}
=========
A lot of examples show datasets, but they're an unnecessary overhead and somewhat complicate the name changing thing.
In the example follows there's a gridview shows the data the report will also use.
So the app builds a sql string, uses that to create a datatable which it both stores in session and binds a gridview to.
Re-using the one data access to provide data for the grid and reportbut f course at the cost of storing the datatable in the web server's memory.
Creating the datatable:
==========
SqlDataAdapter da = new SqlDataAdapter(s, DB.connString);
dtRisks = new DataTable();
da.Fill(dtRisks);
gridRisks.DataSource = dtRisks;
gridRisks.DataBind();
Session.Add("RiskReportData", dtRisks);