August 12, 2011 at 3:26 am
Could anyone explain the difference between a static and insensitive cursor? On the face of it they seem very similar. Both copy the result set to tempdb and operate on that rather than on the underlying table, and both prohibit the modification to data.
August 12, 2011 at 7:21 am
I think the more important question is how can you eliminate your cursor and therefore not really care about some of the subtle details. 😛
Honestly cursors are one the most resource intensive (and SLOW) methods of data manipulation available in sql server. There are a few very rare cases where a cursor is the only way to accomplish something. For everything else there is a much faster set based way of handling things.
If you really want to know the details about your question it can be answered here.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
August 12, 2011 at 11:18 am
You're correct. The definition in BOL is pretty much identical, word for word, except for a final statement in the Insensitive part:
When ISO syntax is used, if INSENSITIVE is omitted, committed deletes and updates made to the underlying tables (by any user) are reflected in subsequent fetches.
I'm assuming this means one of two things. Either 1) STATIC can't be used with ISO Syntax or 2) if ISO Syntax is used with STATIC, it doesn't matter, you still don't get changed data with subsequent fetches.
But I'm guessing.
August 12, 2011 at 1:38 pm
Sean Lange (8/12/2011)
I think the more important question is how can you eliminate your cursor and therefore not really care about some of the subtle details. 😛Honestly cursors are one the most resource intensive (and SLOW) methods of data manipulation available in sql server. There are a few very rare cases where a cursor is the only way to accomplish something. For everything else there is a much faster set based way of handling things.
If you really want to know the details about your question it can be answered here.
I agree with you about 99%. There are situations where I HAVE to use a cursor, especially when producing a result set that has to be passed through a stored procedure call. Keep in mind this is done as a one-off data manipulation process and not used in mainstream production transaction processing. It is certainly easier than having to strip out the code from the sproc and put it into the remaining logic. Yes, in the long run it'd be faster but for a one-off, it isn't worth the extra time and effort
I have found CTEs & the MERGE constructs to be quite handy....
Kurt
Kurt W. Zimmerman
SR DBA
Lefrak Organization
New York, NY
http://www.linkedin.com/in/kurtwzimmerman
August 12, 2011 at 1:50 pm
Kurt W. Zimmerman (8/12/2011)
Sean Lange (8/12/2011)
I think the more important question is how can you eliminate your cursor and therefore not really care about some of the subtle details. 😛Honestly cursors are one the most resource intensive (and SLOW) methods of data manipulation available in sql server. There are a few very rare cases where a cursor is the only way to accomplish something. For everything else there is a much faster set based way of handling things.
If you really want to know the details about your question it can be answered here.
I agree with you about 99%. There are situations where I HAVE to use a cursor, especially when producing a result set that has to be passed through a stored procedure call. Keep in mind this is done as a one-off data manipulation process and not used in mainstream production transaction processing. It is certainly easier than having to strip out the code from the sproc and put it into the remaining logic. Yes, in the long run it'd be faster but for a one-off, it isn't worth the extra time and effort
I have found CTEs & the MERGE constructs to be quite handy....
Kurt
Yes, that is exactly why I said "There are a few very rare cases where a cursor is the only way to accomplish something.". 😛
As with everything in sql server there are no absolutes. "It depends" is still the only unchanging answer.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
August 17, 2011 at 2:15 am
Thanks to everyone for taking the time to read my post and reply.
I agree with what has been said about cursors being a last resort and that there are better alternatives in most cases.
I was really just asking the question out of interest, in that it seems strange to have two cursor types that, from their description on MSDN, appear to be nearly identical.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply