I hear what you're saying about not using a cursor. Unfortunately, there are five-thousand lines of code for the dozens of incentive rules in place. We don't have the programming resources right now to do away with the cursor logic. Also, the other incentive rules take 1-5 seconds to complete; this one takes 9 minutes!

I ran sp_recompile on the stored procedure and got a "successfully marked for recompilation" message--didn't update statistics. Interesting thing is that I had to update part of the sproc when we upgraded the database, but that part of the sproc has no impact on the section where the slowdown occurs. So the bottom line is that I ran the ALTER PROCEDURE for the sproc after restoring the database in SQL Server 2008. Wouldn't that negate the need to update statistics, or does my lack of knowledge on what "update statistics" really does require that I run it?

By the way, I commented out the DATEDIFF logic in the sproc, and it still takes 9 minutes per day of processing. The estimated query execution plan says that 97% of the resources are taken up by a "key lookup (clustered) in SVSales.PK_SVSales". The primary key for SVSales (PK_SVSales) is comprised of the INum and SeqNum fields, the same fields and primary key in the joining table, SVCrossSalesHistory. So I don't know why the estimated execution plan would think the lookup is eating all the resources. I ran a straight-out join of the records between the two tables, and my output windows renders with all 13,000 rows in one second.

I haven't had a chance to put together any sample data...will get on it as soon as I get a chance.