|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Yesterday @ 3:57 PM
Points: 2,550,
Visits: 17,372
|
|
Gaby Abed (2/27/2009)
How many rows would this return? :) (yes...it's different) use AdventureWorks go declare @tableA TABLE(col1 int, col2 int) go --stmt 1 select name from tempdb.sys.tables where name like '%tableA%' --stmt 2 select name from tempdb.sys.columns where name like 'col1%'
I must admit - you TOTALLY had me... I was sitting here going "what??!?!", nothing is different! I even pasted the selects next to each other to make sure they were the same and hadn't changed. So why the different results?
I guess you can tell me "where to go". :D GOT ME!
Chad
|
|
|
|
|
Right there with Babe
      
Group: General Forum Members
Last Login: Yesterday @ 12:30 PM
Points: 795,
Visits: 1,985
|
|
Chad Crawford (2/27/2009)
Gaby Abed (2/27/2009)
How many rows would this return? :) (yes...it's different) use AdventureWorks go declare @tableA TABLE(col1 int, col2 int) go --stmt 1 select name from tempdb.sys.tables where name like '%tableA%' --stmt 2 select name from tempdb.sys.columns where name like 'col1%'
I must admit - you TOTALLY had me... I was sitting here going "what??!?!", nothing is different! I even pasted the selects next to each other to make sure they were the same and hadn't changed. So why the different results? I guess you can tell me "where to go". :D GOT ME! Chad
Yeah, that second go screws you up with table variables. I usually use table variables for very short routines, but they are limited. First in persistence where that second go gets rid of it. The other is that a query similar to this will fail:
insert into @someTableVariable exec someStoredProcecdure
This to me more than anything is the biggest limitation of a table variable. You can't capture values from a stored proc into it.
Gaby ________________________________________________________________ "In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Friday, May 10, 2013 8:44 AM
Points: 565,
Visits: 788
|
|
If I ran these three SQL statements in one transaction, First returns nothing, second returns "col1".
Otherwise, both return nothing.
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: 2 days ago @ 4:12 PM
Points: 382,
Visits: 1,105
|
|
WayneS (2/27/2009)
Interesting. I modified the supplied code to get the # of tempdb objects, and all tempdb table names: use AdventureWorks go select count(*) from tempdb.sys.objects select name from tempdb.sys.tables --where name like '%tableA%' declare @tableA TABLE(col1 int, col2 int) --stmt 1 select name from tempdb.sys.tables --where name like '%tableA%' --stmt 2 select name from tempdb.sys.columns where name like 'col1%' select count(*) from tempdb.sys.objects
and I find that there are no new tables or objects between the two selects from sys.tables. So I modified the sys.columns select to: select sc.name [ColName], st.name [TableName] from tempdb.sys.columns sc INNER JOIN tempdb.sys.tables st ON st.object_id = sc.object_id where sc.name like 'col1%'
What I'm seeing is that the tablename for this table is already in use before the table is declared. I've even tried stopping and restarting the sql service for this instance. What's up with this?
I think the (lack of ) batch separator is causing this. Try this:
select sc.name [ColName], st.name [TableName] from tempdb.sys.columns sc INNER JOIN tempdb.sys.tables st ON st.object_id = sc.object_id where sc.name like 'col1%' declare @tableA TABLE(col1 int, col2 int) select sc.name [ColName], st.name [TableName] from tempdb.sys.columns sc INNER JOIN tempdb.sys.tables st ON st.object_id = sc.object_id where sc.name like 'col1%'
In the above, although we expect to see data for only the second select, we get data from both selects.
In the below select, if you separate the select between batches then you can see the count change.
select count(*) from tempdb.sys.objects go declare @tableA TABLE(col1 int, col2 int) select count(*) from tempdb.sys.objects go
Sankar Reddy | http://SankarReddy.com/
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 9:02 AM
Points: 1,196,
Visits: 1,320
|
|
If I run these statements I get zero and zero, etiher separately or as a batch. If I add in the GO immediatly after the DECLARE, I still get zero and zero - because the table variable is no longer in scope. If I add in place of the GO, SELECT * FROM @TableA then I get zero and 1 - the col1 in sys.columns only appears when I use the table.
Still I now know what the question was attempting to test: I found my temp table @tableA eventually and its called #32DA39A
Using SQL Server 2005, compat level 90
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Wednesday, July 25, 2012 9:04 PM
Points: 542,
Visits: 187
|
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Monday, February 18, 2013 10:54 PM
Points: 371,
Visits: 110
|
|
| For 2005, i get 0 rows returned for both the statements. Why?
|
|
|
|