So ADO.net is the one that declares and populates the variable before calling the stored procedure.
For what it’s worth, I do see that SQL Server is able to re-use cached temp tables in this case. And I expect that invoking the stored procedure explicitly (without ado.net’s help) works the same.

Now for what I call ad hoc queries or parameterized queries (where the ADO.net SqlCommand object uses CommandType.Text) ADO.net issues something like the following under the covers:

declare @p3 dbo.BigIntList
insert into @p3 values(1)
insert into @p3 values(2)
insert into @p3 values(3)
insert into @p3 values(4)
insert into @p3 values(5)
insert into @p3 values(6)
insert into @p3 values(7)
 
exec sp_executesql N'SELECT i FROM @list WHERE i % 2 = 0',N'@list [dbo].[BigIntList] READONLY',@list=@p3

And it’s that example that caused us grief and it’s also that example that Microsoft has been able to demonstrate a performance improvement in 2012 because SQL Server 2012 is able to cache and re-use temp tables where SQL Server 2008 and R2 could not.

So now that that’s cleared up. From what you’ve said earlier, I believe that you’re using TVPs in a way where you won’t have to worry about tempdb contention.

** Then I consider @MyListOfInts a table variable the same way that I consider @Tablename a string variable in:

DECLARE @Tablename sysname**

OK, I do not consider them the same thing and here is why…we can say this:

DECLARE @tt AS IntSet; -- Table Type
 
EXEC dbo.SampleDataTypeProcedure 
    @SampleDataType = @tt;

But this:

DECLARE @tt AS TABLE (Value INT); -- Table Variable with the same definition as the Table Type
 
EXEC dbo.SampleDataTypeProcedure 
    @SampleDataType = @tt;

Results in error:

Msg 206, Level 16, State 2, Procedure SampleDataTypeProcedure, Line 0
Operand type clash: table is incompatible with SampleDataType

** So when using stored procedures, I don’t declare and populate a table during the batch, but I do something like the following instead. Table Valued Parameters, A Short, Complete Example **

I think I know where we have a disconnect. The code sample in the article uses the SqlCommand object to map a ADO.NET DataTable to a stored procedure parameter. While there is nothing explicit in the C# code that says “declare a variable of Type BigIntList and populate it then call the proc” under the covers this is what is actually being generated by the ADO.NET object and shipped via RPC to the server when ExecuteReader() is called:

declare @p1 dbo.BigIntList
insert into @p1 values(1)
insert into @p1 values(2)
insert into @p1 values(3)
insert into @p1 values(4)
insert into @p1 values(5)
insert into @p1 values(6)
insert into @p1 values(7)
 
exec ReturnEvenNumbers @list=@p1

It’s entirely possible that I’ve been sloppy with the terms I’ve used to talk about temp table variables and table valued parameters.

Your first question about using a TVP in a parameterized query. What I mean is code similar to the example at the bottom of Temp table caching improvement for table valued parameters in SQL Server 2012. I have a reproduction at the follow-up (linked at the top of this page) which matches even more closely what I mean by TVPs in parameterized queries. That reproduction is likely what you’re asking for.

For your second question, “table variable” and “table type” are not quite interchangeable in my head, but in my examples each table variable that is declared is a user defined type. So when I’ve defined a table type like:

CREATE TYPE IntSet AS TABLE (Value INT)

And create a variable of that type:

DECLARE @MyListOfInts IntSet

Then I consider @MyListOfInts a table variable the same way that I consider @Tablename a string variable in:

DECLARE @Tablename sysname

So when using stored procedures, I don’t declare and populate a table during the batch, but I do something like the following instead. Table Valued Parameters, A Short, Complete Example

I hope I’ve answered your questions. There’s a chance that I didn’t address the thing you’re wondering about.

Thanks for the article. I am huge fan of passing table valued parameters to stored procedures, but am concerned about the contention issues and the lack of tools we have to combat it but I need some clarification on a couple of items from the article.

** But who creates temp tables that often? We did, just by using a table valued parameter in a parameterized query. Since SQL Server began supporting table valued parameters (introduced in SQL Server 2008), we have been gradually moving towards this practice in lieu of sending xml to be shredded. **

Can you please provide a sample of the code you are passing to the database that is representative of “a table valued parameter in a parameterized query”?

** I’m recommending that developers not create temp tables or declare table variables that cannot be cached. For now, this means we use stored procedures for any query that uses table variables or temp tables. **

Are you using “table variable” and “table type” interchangeably here? How would one call a procedure that accepts a table valued parameter without first declaring it in the batch, populating it, and then passing it in as a parameter in a similar fashion to what the code sample on Books Online shows here? http://msdn.microsoft.com/en-us/library/bb510489(v=sql.105).aspx#sectionToggle2

    <action name="plan_handle" package="sqlserver">
      <type name="unicode_string" package="package0" />
      <value>&lt;plan handle='0x000000000000000000000000000000000000000000000000'/&gt;</value>
      <text />
    </action>

I don’t think that it’s a coincidence that finding a query (or even a plan) here is just as difficult as the efforts I describe in the section “Finding Such Queries Is Difficult”. I don’t know what the common cause is, I just know I have to look elsewhere.