Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « Creating A XSD Schema From A Table In SQL Server With FOR XML SyntaxSome PostgreSQL Announcements »
    comments

    Here is a nice little tip that I noticed is often overlooked or just not known.

    When you have a report that has several datasets supplying multiple objects in the report and these objects are linked based on the selection of parameters in a parent object, you do not need to create multiple parameters and set them with expressions to the parent parameteres. All you need to do is write your procedures and reports to use the same name across the board.

    Here is what I mean by that.

    Say you have your first procedure like this

    1. Create Procedure FindOrders(@date datetime,@plant smallint)
    2. As
    3. Select
    4.  OrderNum
    5.  ,OrderDate
    6. From
    7. Orders
    8. Where
    9. Convert(varchar(10),OrderDate,121) = Convert(varchar(10),@date,121)
    10. and
    11. plant = @plant
    12. Go

    You would then call it as a Text statement in the DS as
    Exec FindOrders @date,@plant

    This would be a typical example of searching orders. The users then ask for a cross reference table of orders shipped in the same day. Instead of adding a column to the table, they want an actual table next to the other.

    Like this layout

    Most would be inclined to create another procedure and then create matching parameters for that report. Then use the "Parameters!" call to assign a default value to the parameter going to the second procedure. You can bypass this by simply naming the parameters in the procedures the same and then call them in your dataset as Text and using the same names.

    So your second procedure would be something like

    1. Create Procedure FindShippedOrders(@date datetime,@plant smallint)
    2. As
    3. Select
    4.  shipdate
    5.  ,OrderNum
    6. From
    7. Shipping
    8. Where
    9. Convert(varchar(10),shipdate,121) = Convert(varchar(10),@date,121)
    10. and
    11. plant = @plant
    12. Go

    You would call this as
    Exec FindShippedOrders @date,@plant

    Now when you check the report parameters window you will still only see two parameters. Run your report and you will see the parameters load while working with both datasets.

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
    Social SitingsTwitterLinkedInLTD RSS Feed
    4449 views
    Instapaper

    5 comments

    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Please don't take my quickly and sometimes poorly written examples to heart when writing your procedures. As you can see, "CONVERT(VARCHAR(10),shipdate,121) = CONVERT(VARCHAR(10),@DATE,121)" is a nonsargable statement. :)

    I'll work a bit harder not to inadvertently post bad statements when showing the results to the main objective.
    05/11/09 @ 12:07
    Comment from: SQLDenis [Member] Email
    *****
    SQLDenis You know i was going to raise hell for that WHERE clause :-)
    This is also why I welcome the date datatype in SQL Server 2008, shaves off 5 bytes of storage and goes to the year 1 instead of 1753
    05/11/09 @ 12:41
    Comment from: David Forck (thirster42) [Member]
    ***--
    Nice, but could use some more detail.

    The reason why this works is that you are naming the sp parameters the exactly the same, and when you create the data sets based on those sps bids creates the parameters for you. you can, however, achieve the exact same thing without having to have the sp parameters be spelled exactly the same.

    under the dataset properties under the parameters tab, you can assigned a report parameter to a stored procedure parameter, no matter the spelling.

    i think i'm jsut rambling... good blog though.
    05/11/09 @ 12:58
    Comment from: chitra [Visitor]
    *****
    chitra It is very Nice..
    Thank u for posting.
    05/25/09 @ 01:00
    Comment from: chitra [Visitor]
    *****
    chitra Hi,
    I am having one doubt here two stored procedures are used here.But if i am using single stored procedure,in the first one reurning the values SELECT
    OrderNum
    ,OrderDate
    FROM
    Orders
    and second one returning the values
    SELECT
    shipdate
    ,OrderNum
    FROM
    Shipping.In this situation i have created two datasets,but it is taking first table values like (ordernum,date alone) It is not considering (shipdate
    ,OrderNum).Can u please tel me how to solve this issue??
    05/25/09 @ 03:17

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)