It's correct... there is a very minor amount of logging for Temp Tables and none for table variables.  The fact that Temp Tables can use statistics and Table Variables cannot...

Emphasis... when a session is completed, the Temp Tables are automatically dropped.  I don't believe there's a way for you to loop through TempDB to figure out which are "yours". ...

I prefer Remi's solution... shorter transaction... fewer actions within the transaction... maybe fewer deadlocks.

Oh, be careful... I could be wrong but I'm thinking that if you have an insert of more than one user, you'll only get one value for @user_ident for that...

Hoooo-boy!  Do I understand that!  My rants peel paint, knock bricks out of old buildings, and embarrasses seasoned sailors   not to mention causing...

About the only thing I'd change is I'd remove the declared transaction.

Like table variables and some views, temp tables use memory and spill over into temp db disk space if they get too big.  It's a good idea to have a...

Any translation of a DATETIME to anything character based or though most UDF's will be slower than doing some simple math using date functions...  try this...

WHERE TransactionDate >= DATEADD(dd,DATEDIFF(dd,0,@TDate),0)

 ...

One picture is worth a thousand words... great explanation...

Nicely done, Remi...

Running the code to create a stored procedure is not the same as running a script... the stored procedure will allow for "deferred naming" until runtime.  This is so you...

http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=8&messageid=348736#bm348757

Heh... first, I'm not into "biting balls"    And, I'd have to say "lack of planning on somebody's part, did constitute and emergency on...

I can't really imagine assigning all users to every new project and vice versa... but, if you must, put a trigger on the User and Project tables that does it...

Scientific and Engineering notations...