• davoscollective (8/1/2012)


    Are relevant temp tables contained within the contained database as well, rather than tempdb?

    I may be wrong, but I am certain that contained databases temp tables are in tempdb.

    Why should they be in the contained database? At first sight hey don't exist while the database is closed (that's the defining property of a temp, as opposed to ordinary, table), and any time it's open it has access to the tempdb of the system it's open on. So whether they are intempdb or somewhere else could make no difference to moving the database from one SQL server or instance to another, and hence is irrelevant to containment.

    "Temporary tables created when a contained database is active will be created using the collation of the contained database instead of the tempdb database."

    That of course is essential to containment - if it weren't true, moving to a different instance with a different default collation might mek the database sease to function correctly.

    in BOL: http://msdn.microsoft.com/en-us/library/ff929080.aspx

    There is a table under the Contained Databases heading that says Temp Data will use DATABASE_DEFAULT for a contained database. I am probably misreading it but to me that means it won't use the CATALOG_DEFAULT of the contained database. What am I missing there?

    [/quote]

    You aren't missing anything - except perhaps the catalog collation for contained databases is fixed and the same for all contained databases. This can happen when a connection flips fromone database to another - see examples two and three at the bottom of the page to which you refer.

    The examples mentioned above seem to me to make it clear that the temp tables, despite the collation issue, are still in tempdb - eg in example 3 it's quite clear that the attempt, while the thread is using the contained database, to access a table whose name begins # is made in tempdb, not in the contained database, while in example 2 it's quite clear that a thread running in non-contained master database accesses a table beginning # in tempdb even though it was created while the thread was using the contained database.

    Of course it would be possible to achieve those effects by by an enormously complicated mechanism that didn't have contained databases temp tables in tempdb, but it really would be enormously complicated, especially when one considers that the files sizes for the contained database have to remain sane, that we generally want tempdb on a different storage unit from the contained database data and logs for performance reason, and that these temp tables in the contained database would have to be omitted from all backups of the database and not exist on instance startup.

    On the replication item, I clicked no because the BOL entry says Partially Contained databases cannot use replication, however on closer reading it says "In SQL Server 2012 the contained database feature is currently available only in a partially contained state".

    I think that all contained databases are partially contained. At least in SQL 2012.

    Tom