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

    « SQL Advent 2011 Day 19: Filtered IndexesSQL Advent 2011 Day 17: varchar(max) »
    comments

    In my Are you ready for SQL Server 2012 or are you still partying like it is 1999? post, I wrote about how you should start using SQL Server 2005 and SQL Server 2008 functionality now in order to prepare for SQL Server 2012. I still see tons of code that is written in the pre 2005 style and people still keep using those functions, procs and statements even though SQL Server 2005 and 2008 have much better functionality.

    Today we are going to take a look at Table-valued Parameters (sometimes also called table types or just TVP). When you create a table type, the table definition is preserved in the database. When you create a table variable later based on that table type you will use the table definition of the table type, you don't have to specify it again.

    Table-valued parameters have the following restrictions:

    SQL Server does not maintain statistics on columns of table-valued parameters.

    Table-valued parameters must be passed as input READONLY parameters to Transact-SQL routines. You cannot perform DML operations such as UPDATE, DELETE, or INSERT on a table-valued parameter in the body of a routine.

    You cannot use a table-valued parameter as target of a SELECT INTO or INSERT EXEC statement. A table-valued parameter can be in the FROM clause of SELECT INTO or in the INSERT EXEC string or stored-procedure.

    Here is a small code example, this will create a new table type named SysObjectsCount with 2 columns

    1. CREATE TYPE SysObjectsCount AS TABLE(quantity INT, xtype CHAR(2))
    2. GO

    Now when we create our variable, we can create it as type SysObjectsCount, this will be almost the same like a table variable but there is no need to specify the table structure. We can insert and select from the variable without a problem

    1. DECLARE @mySystableCount AS SysObjectsCount
    2.  
    3. INSERT @mySystableCount
    4. SELECT COUNT(*),xtype FROM sysobjects
    5. GROUP BY xtype
    6.  
    7. SELECT * FROM @mySystableCount

    The nice thing is that we can actually pass this table type variable into a stored procedure. Create the following stored procedure, the parameter has to be declared as READONLY. You can also not modify the table inside the proc, if you try to do so, you will get the following error

    Msg 10700, Level 16, State 1, Procedure prSysObjectsCount, Line 5
    The table-valued parameter "@mySystableCount" is READONLY and cannot be modified.

    1. CREATE PROC prSysObjectsCount (@mySystableCount SysObjectsCount READONLY, @xtype CHAR(2))
    2. AS
    3. SELECT * FROM @mySystableCount
    4. WHERE xtype = @xtype
    5. GO

    Now run the following piece of code, as you can see we are running the proc three times, each time with a different value for @xtype

    1. DECLARE @mySystableCount AS SysObjectsCount
    2.  
    3. INSERT @mySystableCount
    4. SELECT COUNT(*),xtype FROM sysobjects
    5. GROUP BY xtype
    6.  
    7.  
    8. EXEC prSysObjectsCount @mySystableCount,'P'
    9. EXEC prSysObjectsCount @mySystableCount,'U'
    10. EXEC prSysObjectsCount @mySystableCount,'S'
    Output
    
    
    quantity    xtype
    ----------- -----
    1365        P 
    
    quantity    xtype
    ----------- -----
    21          U 
    
    quantity    xtype
    ----------- -----
    74          S 

    As you can see, the Table-valued Parameter can be passed to the proc and in the proc itself we can filter what we need.

    Another example would be for reporting, let's say the output is always the same but the input differs. You create a Table-valued Parameter, you do your logic on the Table-valued Parameter and after that you pass the Table-valued Parameter to the stored proc. This way you can reuse the proc since the logic in the proc doesn't have to be changed.

    I am sure that you written code where you populate a temporary table and then call a proc, since the proc is in scope the temporary table is available inside the proc. Table-valued Parameters could be used to replace the temporary table approach, however you can't modify the Table-valued Parameter, so this might not work for all your needs.

    That is all for today, come back tomorrow for the next post in this series, we are going to to take a look at indexing

    About the Author

    User bio imageDenis has been working with SQL Server since version 6.5. Although he worked as an ASP/JSP/ColdFusion developer before the dot com bust, he has been working exclusively as a database developer/architect since 2002. In addition to English, Denis is also fluent in Croatian and Dutch, but he can curse in many other languages and dialects (just ask the SQL optimizer) He lives in Princeton, NJ with his wife and three kids.
    Social SitingsTwitterFacebookLinkedInHomePageFlickrLTD RSS Feed
    657 views
    Instapaper

    No feedback yet

    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.)