Contained database temporary tables

Question

Contained database temporary tables

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply

WayneS SSC Guru Points: 95409 More actions · Answer 1

Peter, now I'm confused. How does this question contradict this database being independent of the instance that it's running on? That is exactly the idea behind a contained database.

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

TomThomson SSC Guru Points: 104773 More actions · Answer 2

Peter Trast (4/14/2011)
I made the same wrong guesses as the majority. Got the first one right on collation but guessed that metadata would be in the contained database since my understanding was that these contained databases would not have instance dependencies. Sounds like that is not strictly true.
Gotta read more now!!! 🙂 Great question. I think we need more Denali questions. Any rumors on the actual name of this new version? Is it just SQL Server 2012 (sounds so forboding). I think "Maya" might have been a more interesting code name for 2012 😀

I imagine that when you move a database to a new server, it doesn't at that point in time have any temporary tables. After all, the database needs to be quiescent when you move it, it can't have any active connections so there is no context (except perhaps a transaction context in the log, but then recovery will eliminate the temp table anyway) in which the temp table could exist. So having its metadata in the system collation instead of the database collation does not introduce any dependency on the instance in the sense that "dependency on the instance" is to be eliminated by contained tables, because when something creates the temp table on the new instance the metadata that used to exist on the old instance has no effect on anything at all.

Tom

WayneS SSC Guru Points: 95409 More actions · Answer 3

Just to make sure you understand... the temporary tables still physically reside in tempdb. They still show up in tempdb.sys.tables and tempdb.sys.columns (indexes, constraints, etc.) They are just of the collation of the contained database instead of tempdb.

For instance, if you run this in a contained database:

USE ContainedDB;

GO

CREATE TABLE #TestTable (

RowID INT IDENTITY PRIMARY KEY CLUSTERED,

SSN char(9) NOT NULL UNIQUE,

Age tinyint CHECK(Age>18));

CREATE INDEX IX_TestTable ON #TestTable (Age, SSN);

declare @object_id int;

set @object_id = object_id('tempdb..#TestTable');

select * from tempdb.sys.tables where object_id = @object_id;

select * from tempdb.sys.key_constraints where parent_object_id = @object_id;

select * from tempdb.sys.check_constraints where parent_object_id = @object_id;

select * from tempdb.sys.indexes where object_id = @object_id;

select * from tempdb.sys.objects where type = 'U';

You will get returned to you all of the meta-data from tempdb for this temporary table.

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2