Yes, that is awful indeed. I found that out the hard way, when I decided to add "always name constraints" to my list of best practices to follow. I changed some code, tested, then quickly removed the constraint names for the temp tables. For those who never tried - it'll give you errors. If you create a table named #temp, SQL Server will apply some magic to give it a real name that's unique and that maps to the #temp pseudo-name. If you add a constraint named pk_#temp to that table, SQL Server will do no magic at all; it will simply use that constraint name - and give you an error message ("there is already an object named pk_#temp in the database") as soon as a second connection runs the same code before the temporary table from the first connection has been removed.