Query/report parameters vs RS filters vs SPs

  • Picture a product hierarchy: class, subclass, item.  I'd like to allow the user to report the details on a single item, on a subclass, or on an entire class.  If I reference 3 parameters in the dataset query, as I understand it, I have to provide all three values as the blank/null will be passed to the query if the parameter is set to allow blanks/nulls.  Is this correct?

    The alternatives I read about in the WROX RS book include using stored procedures and report filters.  Filters let the database select the same (larger?) amount of data, but the report will use the filter to limit the amount of data rendered.  In this case the dataset would bring back everything for a class, and the subclass and/or item values would limit the data rendered. 

    A stored procedure would allow me complete control of the data returned as it could issue a different query depending upon which parameters were filled in.

    Am I understanding this correctly?  Are there other options?

    Thanks,

    Larry

    Larry

  • Hi Larry,

    In my oppinion I would want the least amount of data coming down the line so I would try using a query using the isnull function or a stored procedure.

    Regards

    Col

  • Larry,

    I agree with Col.  You always want to make sure that you have the least amount of traffic going down the wire.  Also, depending on the reporting tool you're using to do the rendering, you may experience performance degradation once you start dealing with larges amounts of data.  In my experience you always want to use a tool for the job it does best.  In this case use SQL Server to query and filter the data and use the reporting tool to render (not to filter, etc).

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply