I might also check the timing of

delete from ... where 1=0 

I have come across cases where doing nothing could take a long time. 

Temp tables, cursors, and execute ad hoc in a trigger!  No wonder you're having problems.  Better check the procs called also. 

That's what I expected.  I used the VC++ IDE years ago with a database project.  It would do the same thing for you.  It also let you script the change...

Look in BOL for SET IDENTITY_INSERT.  There is info there that should be understood before using this.   

SET IDENTITY_INSERT [ database. [ owner. ] ] { table } { ON |...

The select portion of the query used is the trigger is often the difficult part.  It can be developed and tested in QA before the trigger is even started. 

If...

I would start with georgedo's solution.  You can test the guts of the query on the entire table.  Replace the inserted table with the original trigger table.

      select -- perhaps a...

georgedo,

I was indeed.  Your trigger, without local variables and using group by, is a clear sign you are multirow aware.  And the group by is a clear sign you...

Is the problem that the log just keeps getting bigger?  If you do not need transaction log backups for recovery, then you can set the recovery model to simple so...

The trigger fires once even if 0, 1 or many records are affected.  Using local variables is not good - please, no cursor in a trigger - in this case...

The update query with local variables could also work if the sums are account specific.  A local variable could hold the account number.  If the account number changes, the

Maybe this would be better - no need for in or out to be zero in Record 1. 

SET @Balance = Balance = CASE WHEN Record = 1 THEN Balance...

Since you're processing the records one at a time forward, perhaps an update query using local variables will work.  Putting an order by into an update is not easy - I...

I like to use the dts copy objects task as well.  However, I first script the logins using "sp_helprevlogins" - see "Migrating Logins To Another Server" on this site.  This...

Here is another batch that includes the buggy result.  In the last query, the output has the same number of records as in #temp (776937) rather than 1.  This is...

...and thanks for the tip.  These queries are fast enough that comparing relative times in one batch via the execution plan window is nice.