ryIf you can use a query to get what you want you should never use a cursor.
Cursors are best for maintenance type tasks where you need to loop thru say
a collection of tables and do something such as reindexing. As for data use
they should be used as a last resort only. Sometimes it is just not
practical or even feasible to issue strictly set based commands and get what
you want so a cursor might be necessary. For instance if you have to do
some work on each row that can only be done thru calling a stored
procedure(s) you might create a cursor and loop thru calling it for each
row. Otherwise try to use standard set based commands.
Andrew J. Kelly SQL MVP
"Vincent Jones" <vncntj@.hotmail.com> wrote in message
news:ba2a2d30.0401140615.581598f2@.posting.google.com...
quote:
> Can someone give me an example of when I would use a cursor instead of a
query|||In a properly designed database the occassions when a cursor is a good and
efficient solution to a problem are rare.
Sometimes cursors are useful for certain administrative functions or for
processes such as Andrew described.
Very occassionally you find a data manipulation problem which doesn't have a
feasible set-based solution. If you think you've encountered one of those
situations then post your problem here and see if someone else can suggest
an alternative.
In reality, many examples of cursor code are written by programmers who
aren't familiar with SQL and are more comfortable with row-by-row sequential
processing than with set-based SELECT statements. So for data manipulation
problems my general rule would be: If you think you need a cursor - think
again. If you're sure you need a cursor - get a second opinion.
David Portas
--
Please reply only to the newsgroup
--
No comments:
Post a Comment