Most likely that a new set of parameters was passed to the stored proc and the cached plan was not optimal for those parameters.

Check out parameter sniffing on this site...

Here's the correct syntax to do the update.

UPDATE A

SET Col1 = B.Col1,

col2 = B.Col2,

Col3 = B.Col3,

Col4 = B.col4

FROM Table1 A inner join

(SELECT Col1, Col2, Col3, Col4, id FROM Table2

UNION...

You can or you can't imagine any reason?

You can do a union all between b and c and use that data to do the update.

Or you can simply do 2 different updates.

What is this doing in there?

DECLARE @val bigint

SELECT @val=COUNT_BIG(*) FROM Table1 WITH (READCOMMITTED)

Can we see the rest fo the statement, maybe there are other alternatives to this problem?

Why are you not joining simply on the id column(s)?

Try changing the update query to a select and see if it returns row(s) (which I would think not).

If no rows...

What error are you getting?

What is not going on as you'd want it to go?

Why not simply drop the destination table first, and then reimport it?

Thanks for sharing this with us.  Care to write a small article about this one and submitting it to Steve ?

It's kind of hard for us to help you if we don't know what's going wrong with your code!!

A date is a place in time, hence you can't have a date without time.  If you don't want to display the time you can either have the application hide...

Or another way to do this :

- Insert into temp table in the correct order

- Run a single update statement calculating the running total

- Select from temp table

Option c...

Yup, no need for a cursor nor a temp table.  However this is one rare case when the cursors and temp tables beat the set based (in case of triangular...

Ben, run all 3 versions of your code and see for yourself.  Even at 10 000 rows, the convert will most likely be constantly slower.  At millions it's not even...

Check out those tables, then all you'd need to do is pivot the data :

Select * from master.dbo.SysUsers

Select * from master.dbo.SysLogins