I have a question regarding a piece of documentation on Temp Tables that I recently read on TechNet. The fourth paragraph of the Temporary Tables section on that page reads as follows:
If a temporary table is created with a named constraint and the temporary table is created within the scope of a user-defined transaction, only one user at a time can execute the statement that creates the temp table. For example, if a stored procedure creates a temporary table with a named primary key constraint, the stored procedure cannot be executed simultaneously by multiple users.
I work in an environment where we make significant use of a handful of stored procedures that use indexed temp tables, and we've never encountered an issue where users are having to wait for one execution to complete before the next begins. I hope that will continue to be the case, but I'm concerned that it could become an issue if this caveat is not properly understood.
Specifically, I am unclear on the following points:
- Does this apply only to global temp tables, or to local ones as well? It seems strange that a table that isn't visible outside of the session (as in the latter case) would prevent another session from executing simultaneously.
- What qualifies as a "named constraint"? Don't all constraints have names (even if they are system-generated)? Is this referring to constraints with a user-defined alias? This seems like poor phrasing to me.
- Does "multiple users" actually mean multiple sessions? These procedures are called through our application using a single service account, so 99.9% of calls to our scripts are made to the DB by that single account (and I'm unconcerned about the occasional call an admin may make on the backend). If the service account can run the sproc in multiple sessions simultaneously, then this issue is moot for my purposes.