USE [master]
GO
/****** Object: StoredProcedure [dbo].[b] Script Date: 04/28/2013 01:09:39 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER proc [dbo].[b]
as
begin
declare @i table (id int)
select * From tempdb.sys.tables
end

and after i ran the executed my proce

exec b

The result is :
name objectid
#023D5A04 37575172 and so on…

i closed the above connection and after i opened new connection and ran the query like

select * from tempdb.sys.tables

it is showing the below result and table exists in tempdb with the name:

The result is :
name objectid
#023D5A04 37575172 and so on…

Question is:
Why did not it automatically dropped when i ran procedure and even i closed the connection please help on this..

Thanks,
Dastagiri

if @l_Class_Code ’55′
begin
SELECT row_number() over(order by t.Class_Code) as srl,t.*
into #TmpPolicyDetails
FROM uplPolicyDetails t
Where convert(nvarchar(10),DateReceiptatTpa,103) = @DateReceivedAtTpa
and Office_Code = @BranchCode
and LocationID = @LocationID
and UploadedByID = cast(@UserCode as nvarchar(20))
and Class_Code = @l_Class_Code
and Updated = ‘N’;
end;
else
begin
SELECT row_number() over(order by t.Class_Code) as srl,t.*
into #TmpPolicyDetails
FROM uplPolicyDetails t
Where convert(nvarchar(10),DateReceiptatTpa,103) = @DateReceivedAtTpa
and Office_Code = @BranchCode
and LocationID = @LocationID
and UploadedByID = cast(@UserCode as nvarchar(20))
and Class_Code = @l_Class_Code
and cast(rtrim(ltrim(DevOfficerID)) as int) = @l_DevOfficerID
and Updated = ‘N’;
end;

set @var1=12500
set @var2=NULL
set @var3=500

select @var4=(@var1+@var2+@var3)

print @var4

Why its not print the value sir…

Thanks for the article. I noticed the below with your example. When I execute the below query

SELECT *
FROM sys.dm_db_session_space_usage
where session_id =

I see after creating temp table the user_objects_dealloc_page_count value is 0. But After creating table variable the value is equal to the pages created. It seems, the pages are deallocated and the data is kept in memory incase of table variable. I also read an article which says, table variable will flush the data to tempdb when it come across memory pressure.

The only reason I can think of when I use temporary variables against temporary tables is when I have to perform ROLLBACK operation.

Like some one mentioned above in their comments. Rollback operation also rollesback data from temporary tables. I usually do logging in temporary variables and even if the transactiosn rollsback, I still want to see why the transaction failed and until what point it executed with no errors. I capture all this information in table variables, on error I rollback the transaction but I still have all my information logged in table variables which is not rolledback which I then write to my permemnant tables as part of error handling.

There is a difference in scope of Table Variable and Temporary table. I usually prefer Temporary tables over table variables when working with Dynamix SQL, they are easy to work with.

~ IM.

Table Variable has to be defined and declared, unlike a temporary table.

You cannot get a structure into a Table variable unlike temporary table.

Simple example to declare a table variable.

Declare @Example Table (Eid int NOT NULL, EmpName varchar(40) NOT NULL)

There is always an option to go dynamic and build a table variable by reading the source table structure, but I dont recommend it unless it is absolutely neccessary. If the table structure does not change, then declare the table variable as shown above.

Hope this helps.

~ IM.

I think , I should adopt table partitioning concept on main transaction table and based on that i will go forward in my GUI.Is it Fine or what step should I adopt.

Please Clarify ASAP . Thanks.

On which basis we will distinguish Large Table and Small Table.

Can I say transaction table as Large table and master table is small table.Please Clarify . Thanks.

Can you Please tell me , in a distributed environment if I use temp table , am I going to face any performance issue.

Thanks

Can you correct the heading of your article which says “Temp table in memory a myth”….It should be “Table Variable in memory a myth”

BEGIN
– Create Table Variable and insert three thousand rows
DECLARE @temp TABLE(Col1 INT)
INSERT INTO @temp (Col1)
SELECT TOP 3000 ROW_NUMBER() OVER(ORDER BY a.name)
FROM sys.all_objects a
CROSS JOIN sys.all_objects b

SELECT * FROM tempdb.sys.objects order by create_date desc
END

Temp tables may have indexes added and table variables only can have Primary and unique key constraints as indexes.

Table variables are dropped at the end of a batch but temp tables are dropped at the end of a session / stored procedure

Table variables are not transactional and do not roll back. temp tables are transactional and do roll back.

Temp tables are visible to called procedures but table variables

Query optimizer always assumes that one row is returned from a table variable. Temp tables with indexes have statistics that generate better plans.