none
Local Report and Data Source RRS feed

  • Question

  • Hi,

    I have a requirement to be able to load a local report from disk in an ASP.Net (c#) application.
    The report(s) are not pre-defined, and so it is not possible for me to write code in order to retrieve the data for them.

    Is there a way of defining the datasource (an SQL Server) within the report, or another file which the report viewer control would use to get the data to supply to the report (Or that would tell me how to get the required data)


    Thankyou.


    Paul
    Tuesday, September 4, 2007 10:51 AM

All replies

  • Yes there are a couple of ways...

     

    What is defining the RDLCs for you?  Are they created by the designer in the normal way?

     

    I ask because, if they need to be edited in the designer and possibly re-edited later, there are some restrictions on the ways you can add into the document and ensure that the nodes will be retained.

     

    If they are being programmatically created or something like that, you have more choices.

     

    FWIW I've been working on a utility that will allow you to add custom information of this type and others into RDLs and RDLCs directly from the designer -- it works now for RDLs, although I haven't posted it anywhere.  I was thinking of posting a deployable version this weekend, actually.

     

    Because it has a designer-oriented mode, so it observes the restrictions I'm talking about.  Here's a link to the proto docs -- http://spacefold.com/articles/XMLRSDocs.aspx.

     

    IAC I'll just share what I know about ways you can add into the RDL and RDLC, with or without using RDLDocumenter, gladly <s>. In your case you could probably add the data sources in as if it were an RDL rather than an RDLC. The local mode would ignore them but your code could pay attention them.  Alternatively, I'd use custom properties of the report node. 

     

    If you don't use the designer to edit these reports, again, you have more flexibility -- in this case I would use namespaced nodes of your own design.  The designer would blow them away but it is much the best way to add custom, complex content into any xml document.

     

    >L<

     

    Wednesday, September 5, 2007 4:03 PM
  • The situation is as follows:

    - The reports are created in the designer and saved to disc as an RDLC file.
    - They are then 'loaded' into my application by selecting the file on disc, and I copy it to the web server.
    - I then have a report viewer, which allows the user to select one of the reports that have been uploaded, prompts them for parameters and displays the report.
    (I have this working for Cystal reports, and SQL RS Server reports already)

    Your application may be useful, but ideally I could 'inject' this extra information at the point of upload, as I could enuire about the data source at that point. The only problem then though, is will the Report Viewer control do anything with it, or will I need to do that?


    Thankyou for your response.


    Paul
    Wednesday, September 5, 2007 4:13 PM
  • In local mode, the report viewer will do absolutely nothing with the datasource information you've injected, regardless of how you "phrase" that information within the RDLC.

     

    XMLRSDocs isn't exactly an application, although it has application components such as RDLDocumenter.  It's more of an idea (see http://spacefold.com/lisa/post/Introducing-XMLRSDocs-and-RDLDocumenter.aspx for my attempt to explain that idea) about enriching RDL content with additional custom metadata.

     

    What you do with that custom data is up to you.  (In the case of an RDLC, datasource information, again, *is* custom data).  In XMLRSDocs case, it's useful to have extra data in a report for documentation purposes. In your case, you want to pull it out and use it to fill a data source followed by invoking the report.

     

    My app's test harness actually does something like this (because it dynamically loads the data for the reports it produces from whatever RDL(s) and/or RDLC(s) you indicated you wanted to document).  It's not that hard.  Is this the part that you're having a hard time with?

     

    Let's divide the problem into two parts:

    1) You have to decide how to store your custom information in a manner that gives you the data-awareness that you need at runtime.  I was suggesting that you follow a similar strategy to what RDLs use for this purpose in a server report or, alternatively, design a simpler notation and use custom properties to store what you need.

     

    2) Once you've decided how to store it, extracting can be done through the DOM (pretty simple) or XSLT (which I prefer in general but here you have a couple of nodes you want to grab, I'd use DOM). So your app grabs the data info, loads your datasets, invokes the report.

     

    Which part is giving you a hard time, or maybe it's both?

     

    >L<

     

    Wednesday, September 5, 2007 4:24 PM
  • Well there are issues with both parts really, but the biggest stumbling block is point 2 - working out what data is required and how to get it.

    The datasources will normally be tables / stored procedures on an SQL server.


    Thanks.

    Paul
    Wednesday, September 5, 2007 4:33 PM
  • If you have an appropriate notation, this shouldn't be that difficult.

     

    To get started, can you make the simplifying assumption that the data always come from a single known datasource, or do the sources sometimes switch as well as what tables/stored procs you want to use?

     

    You can do it either way but there are extra steps in dynamically setting up the whole thing starting with the connection if you don't know what the source is before you start. 

     

    Even if there are multiple potential datasources, often you can set up one as the focal point of the operation and design some special execution procs on that one, through which your other statements are funneled (I used linked servers a lot and one server is the focal point through which the other sources are invoked). 

     

    You can lift your statements out of your specialized metadata, pass it to one proc, and have that one proc always return the data.  That cuts out a *lot* of work and is not that hard. 

     

    Now that I think about it -- I've done this for other purposes, but not in this context -- it might work out great for you here. If you want to go this route but don't think it will work for you you might want to supply some examples illustrating why and I will explain what I would do <s>.

     

    If you want to go a route where more is done in the managed code layer rather than in a super-generic sproc, you can certainly do that too  -- that's what RDLDocumenter's test harness does.  In fact it starts one more step "back" than you are likely to do since it first evaluates "is this connection a SQLCEConnection or a SQLConnection?" before going on to do the rest of the dynamic binding <s>.

     

    I need to leave for work and don't have much time to illustrate now but this is one in a long list of subjects I have been trying to find time to write a post about.  If you need it I will move it to the top of my queue <s>.

     

    >L<

     

     

     

     

    Wednesday, September 5, 2007 5:09 PM
  • I would appreciate it if you could illustrate it, as this is a new area for me, and a little help would be most welcome. You know how it is, I just need to get it done, along with a long list of other things.


    Thankyou again.



    Thursday, September 6, 2007 2:50 PM
  • >> You know how it is, I just need to get it done, along with a long list of other things.

     

    Everyone is in the same boat <s> -- and this is not actually something I have a need to get done -- so I would appreciate your narrowing down the aspect of what I am describing that you most need examples of??  I will do my best to help.

     

    >L<

    Thursday, September 6, 2007 4:05 PM