IMO......(as a point of order on some words used above, but not on the subjective matter under discussion)

Facts do not need interpreting, opinions can be.

"1+1=2" is a fact and has...

I'll be generous and say it's not my original work....Robvolk or NR from SQLTeam.com provided that wisdom.

What you've seen from PW is a SET-BASED solution to your problem.  A real world comparison to a CURSOR-BASED solution (which you started off looking for) is the comparison of...

maybe point them here then!!!!

Good luck with your travails....getting rid of the cursor should solve more than 1 problem....1 definite one you have...and 1 you may not be aware of...(performance)

Yup....post the code so that we can examine it.....and get rid of the cursor.

If you don't know why I'm advocating the latter route....search here for 'good performance' and 'cursor'.....the 2...

i think you are misunderstanding the nature of "set rowcount".

it doesn't refer to specific records...it limits the number of records being processed by all subsequent select/update/delete statements on the connection...

no...just the inner loop is required.

try it...with a small number/small dataset!!!

don't worry about the vb style....that's my environment too.

code as is should be enough...

basically the update keeps getting called until there are no more records to be updated....with at most 10000 records being updated in a batch.

try it...

peter..."recordsupd = @@recordcount"...written in haste!!!

wanted to introduce the principle....not concerned (this time) to solve 100% of the problem.

size does matter...but as long as you manage the items that can hit performance (indices (or lack of), poor queries, lengthy transactions, HW issues...disk perf, disk capacity... locking)...you should be...

last effort at typing not saved for some reason so here goes for a 2nd time...

you need to manage the size of the transaction log...a WHILE loop should suffice.

recordsupd =...

SS has user specific temp tables as well....or rather 'connection specific temp tables' (which allows a user with multiple connections to have multiple same named temp tables)..

look up info on tables with...

I'd seriously advise staying away from cursors...the performance is (99.99% of the time) VERY poor compared to SET-BASED processing.

post the actual SQL query.....a beneficial rewrite might solve more problems than...

before you start.....the best piece of advice you will get for free....

STAY away from CURSORS....poor performance...99% of CURSORS can be done in a SET-BASED manner.....for a fraction of the execution...

interesting views.....however obviously the fact that you are in a completely different timezone from the rest of us gives you an advantage in providing solutions....

"Regular Columnist : Andy Warren

Posted: 09/30/2004...