February 26, 2009 at 11:40 pm
Comments posted to this topic are about the item TSQL - tempdb
[font="Courier New"]Sankar Reddy | http://SankarReddy.com/[/url][/font]
February 27, 2009 at 5:49 am
Why would I get zero and zero when I run this set of queries on SQL 2005?
If it was easy, everybody would be doing it!;)
February 27, 2009 at 6:17 am
Based on the queries supplied, you should get 1 and 1, because the first statement includes the wildcard at the beginning, so the # SHOULD be returned.
February 27, 2009 at 6:28 am
Rich (2/27/2009)
Based on the queries supplied, you should get 1 and 1, because the first statement includes the wildcard at the beginning, so the # SHOULD be returned.
The answer says
"Table variable names inside tempdb starts with '#' followed by hex string"
In which case it wouldn't find it using the name
February 27, 2009 at 6:46 am
This doesn't work on 2000 but it does on 2005.
Baseball is back! :w00t:
February 27, 2009 at 6:47 am
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%'
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
February 27, 2009 at 6:52 am
Longy (2/27/2009)
Rich (2/27/2009)
Based on the queries supplied, you should get 1 and 1, because the first statement includes the wildcard at the beginning, so the # SHOULD be returned.The answer says
"Table variable names inside tempdb starts with '#' followed by hex string"
In which case it wouldn't find it using the name
Oops. Too early in the AM.
February 27, 2009 at 6:55 am
Rich (2/27/2009)
Longy (2/27/2009)
Rich (2/27/2009)
Based on the queries supplied, you should get 1 and 1, because the first statement includes the wildcard at the beginning, so the # SHOULD be returned.The answer says
"Table variable names inside tempdb starts with '#' followed by hex string"
In which case it wouldn't find it using the name
Oops. Too early in the AM.
Yeah, I thought exactly the same thing at first, but after re-reading it spotted that!
February 27, 2009 at 6:57 am
Thanks, skjoldtc!
When you said that I checked my compatibility level on the database I ran the queries on and they were set to 80 which is why I got zeros when I ran the queries.
If it was easy, everybody would be doing it!;)
February 27, 2009 at 8:09 am
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?
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
February 27, 2009 at 8:28 am
Gaby Abed (2/27/2009)
How many rows would this return? 🙂 (yes...it's different)
use AdventureWorksgo
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". 😀
GOT ME!
Chad
February 27, 2009 at 8:34 am
Chad Crawford (2/27/2009)
Gaby Abed (2/27/2009)
How many rows would this return? 🙂 (yes...it's different)
use AdventureWorksgo
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". 😀
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
February 27, 2009 at 12:10 pm
If I ran these three SQL statements in one transaction, First returns nothing, second returns "col1".
Otherwise, both return nothing.
February 27, 2009 at 12:13 pm
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
[font="Courier New"]Sankar Reddy | http://SankarReddy.com/[/url][/font]
March 6, 2009 at 1:40 am
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
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply