none
Why do RDLC files hold connections and SQL command strings? RRS feed

  • Question

  • I wrote a object model that outputs XML in the form of an RDL report. I output such RDL containing a connection string, query and dataset definition and then load it into the report viewer control as a local report. When I run the report I get this error:

     

    A data source instance has not been supplied for the data source 'DataSet1'.

     

    DataSet1 is indeed the name I gave the defined dataset but what does it mean a datasource instance hasn’t been defined?

     

    Why do I need to define a connection string and SQL command query if I’m suppose to define the datasource myself?

     

    Will the local report engine use the connection string and defined dataset to get it’s own data? If not why are these parts included in the XML definition of an RDLC report?

     

     

    Thanks for any info!

     

    Monday, October 15, 2007 12:17 AM

All replies

  • Do not take this as Gospel because I can't remember where I saw it...

     

    However, what I've read is that the dataset integration information is put into RDLCs (localmode reports) to maintain compatibility at some level with RDL (web-based, SQL Report Server based) implementations, but is otherwise unused.

     

    What I've personally noticed with RDLC (localmode) implementations in .Net apps is that the RV designer/wiz's/generators insist on embedding the DS information in the RDLC but otherwise pretty much ignores it, except for the Fields definitions (which appear to be used by the Designer.)

     

    In any event in localmode you define the dataset and ergo it's connection string and so on.

     

    Monday, October 15, 2007 8:51 PM
  • Note that by default DevStudio. the ReportViewer designer, and the Data Source wizard/designer will create and consume strongly-typed datasets.

     

    There are some good reasons to avoid strongly-typed datasets, two that come to mind are that you can't access the query[ies] directly (to replace or change them) once they're defined, and that any changes in schema (such as tweaking a query and thus the resulting table), no matter how small, can break code all over the place (since it's strongly typed.)

     

    Oh, and if you generate/change/remove strongly typed datasets more than once or a few times, eventually code will start to break and you can end up with a mess because in some cases the designers/wizards/etc won't change code, they'll just generate new types and new variables and leave all the old code behind.

     

    YMMV...

    Tuesday, October 16, 2007 2:27 PM