Rollback of Temp Table vs Table Variable

Is there a difference between a Rollback of a Temp Table vs Rollback of a Table Variable? I've read a number of articles about the difference between Temp Table and Table Variable. Not until I have this major project that I got to work on one of the biggest difference between these two types of table. I am required to write, through an existing stored procedure, to a log table that contains description of each major steps on my stored procedure, including error messages. My problem is, I implemented a transaction to handle any error that my stored procedure might encounter. These errors are usually due to violations of constraint, integrity and data type implicit conversions. Once the rollback is executed, I loose all the records in log table that got inserted as my stored procedure executes. The solution: table variable. I created a table variable with the same structure as that of the log table. Records got inserted into log table during the execution of the stored procedure. When an error caused the process to fail, I inserted the value from the log table into the table variable before I executed a rollback. After the rollback, all records that got inserted to the log-table were deleted. Then I inserted everything back from the table variable to the log table. Since table variable are not affected by a rollback statement, the data was preserved in the variable. One major consideration is to figure out which records were inserted by my stored procedure so as not to duplicate the entire table.


~~ CK

Reseeding Identity Column

I received a project that involves inserting thousands of rows into a table with an identity column as its Primary Key. The concern is, with a failed transaction, there is a possibility of significant gaps within the sequence of the column. To handle the requirement, I grab the last identity value right after the transaction starts. This will also lock the table until the transaction is committed or rolled-back. Paired with the TRY..CATCH statement, I was able to rollback the transaction and reseed the table as if the insert did not happen and preserve the sequence of the identity column. I was able to use this technique since I am aware no one else is using the table as this transaction is being executed. If the table is updated frequently, transaction must be handled properly so as not to lock the table longer than necessary.
Here's the pseudo-code:

begin transaction

begin try
set @last_identity_value = ident_current(tablename)
set @last_identity_value =
 case when @last_identity_value = 1 then 0
      else @last_identity_value
 end

/*insert the records to table here*/

commit transaction
end try
begin catch
 rollback transaction
 DBCC CHECKIDENT (tablename,RESEED,@last_identity_value)
end catch

As always, comments are welcome...


~~ CK