In SQL Server 2005 and earlier, it was bit difficult to pass numerous parameters (Table variable) to the T-SQL Statements or Functions or Stored Procedures. The approach we used to take is creating a Temporary Table on Demand and inserts the values to the Temporary Table and then calls it in requisite procedure. In SQL Server 2008 the Table-Valued Parameters have been introduced that helps us eliminating the cumbersome process. This is the ability to easily pass a table to a stored procedure from T-SQL code or from an application as a parameter.
User-Defined Table Type
When first take a look at the new table-valued parameters, I thought that using this feature is a bit complicated. There are several steps involved. The first thing to do is to define a table type. If you look at the Types section under Programmability in the 2008 Management Studio, you will see the new “User-Defined Table Types”
Table-valued Parameters are the new parameter types in SQL Server 2008 and it could be declared by declaring the user defined table types. The Table-valued parameters could be used to send multiple rows of data to a T-SQL statement or routine. Table-valued parameters are like the parameter arrays in OLE DB and ODBC but with better flexibility. It could be used to participate in the set-based operations. Permissions for the Table-valued parameters follow SQL Server Object Model so CREATE, GRANT, DENY, ALTER etc. could be used.
Table Valued Parameters help in the following:
1. They are Strongly Typed
2. We can specify the sort order and the unique key
3. Reduce Round trips to the server
4. We can have the table structure of different cardinality
5. It doesn't need or cause the statement to recompile
6. It doesn't need lock to initially populate the data from the client
7. Enables us to include complex business logic in a single routine
8. It provides a very simple programming model.
Lets start with an example:
Syantax:
After running the above code, the object definition is created and viewable in the “User-Defined Table Type”. You can view the properties there, but not modify them. To modify the type, you will have to drop it and then create it again with the modified definition.
Using the User-Defined Table Type
So far, it seems like we have done quite a bit of work, but we only have the type definition created. Like other programmable objects, it will stick around unless it is dropped. To use it in T-SQL code, you must create a variable of the new type and then populate it as you would any other table. Once it is populated, you can use it in other T-SQL statements. Because it is a variable, it goes out of scope automatically when the batch is completed. Notice in the code below that the name of the data type is the same as the type we just created.
As long as the variable does not go out of scope, you can do just about anything with it that you can do with a regular table variable, such as join another table or be used to populate another table. Like a table variable, you can not modify the table definition.
As I mentioned, the variable is gone once it goes out of scope. For example if you have a T-SQL script that is composed of more than one batch, the variable is only valid within the batch where it was created.
Using the Variable as a Parameter
So far, we haven’t seen anything that is not possible with a regular table variable. The benefit is being able to pass the variable of the new type to a stored procedure. A stored procedure must be created that uses the new type. Here is an example of that along with the code to create a regular table that we will be populating.
Notice the READONLY qualifier after the table parameter. This is required because a copy of the user-defined table variable is not passed to the procedure. To be more efficient, a pointer is passed to the proc. Therefore, to eliminate changes to the variable inside the proc that would affect the original, no changes are allowed.
Finally, let’s put it all together and call the stored procedure. In the next code snippet, code from the previous section is used to create and populate the variable.
In order for a user to use the User-Defined Table Type, EXECUTE or CONTROL permission must be granted. This is the command to grant permission to a user:
GRANT EXECUTE ON TYPE::dbo.MyType TO TestUser;
Calling from a .Net Application
The coolest way to use the table-valued parameter is from a .Net application. To do so, you need to have .NET 3.5 installed and make sure you are using the System.Data.SQLClient namespace. This gives you a new SQL data type called Structured that you will use when creating the parameter.
First create a local DataTable and populate it. Be sure that the DataTable that you create matches the user-defined table type’s column count and data types.
Since we will be working with a stored proc, create a command object and add the two parameters. This code assumes that you have an open connection to your test database.
Notice the data type of the @MyTableParam parameter. This is the new type added with .Net 3.5 to work with this new functionality. Finally, assign the local table to the parameter and execute the command.
Conclusion
The table-valued parameter feature introduced with SQL Server 2008 has been sorely needed. It will allow developers to write much better performing applications by decreasing round-trips to the server and by letting SQL Server work how it does best – on sets of data. It is not difficult to use once all the pieces are put into place.
Let me know if I missed anything...
No comments:
Post a Comment