Cursor in MS Yukon / SQL 2005.

Is Cursor Included in Yukon/SQL 2005. or any alternet solution for that?Yes 2005 still supports cursors. There is already an alternative solution in
earlier versions: set-based SQL code. If you tell us what you want to do
then we might be able to give you a specific solution.
David Portas
SQL Server MVP
--|||Thanks for your reply......
Just i want to know MS has included cursor in Yukon? if yes then any
new feature in cursor? and if no what is the alernet solution for that
thats what i wanted to know....
HItendra|||I'm not aware of any new features of cursors in 2005 but then I haven't
looked for them. If it's important to you then the best place for that
question is the SQL Server 2005 beta newsgroups.
Cursors are almost never necessary in SQL Server and they are seldom a good
idea. Since you haven't told us what you want to do I can't tell you what th
e
alternatives are. "Cursor" is not a specification of a problem - it's just
one type of solution. The better solutions are usually set-based. Set-based
statements operate on the whole set of rows (like SELECT/UPDATE/DELETE/INSER
T
statements) instead of one row at a time (like a cursor). Most of the time i
t
pays to find a set-based solution rather than a cursor because set-based cod
e
is generally easier to develop, test, support and maintain as well as being
much more efficient than most cursor solutions.
David Portas
SQL Server MVP
--
"hitendra15@.gmail.com" wrote:

> Thanks for your reply......
> Just i want to know MS has included cursor in Yukon? if yes then any
> new feature in cursor? and if no what is the alernet solution for that
> thats what i wanted to know....
> --
> HItendra
>|||(hitendra15@.gmail.com) writes:
> Thanks for your reply......
> Just i want to know MS has included cursor in Yukon? if yes then any
> new feature in cursor?
There are no new features with cursors, as far as I know. The version
with the feature-craze on cursors was SQL 7, and I still haven't understood
all of that. Keep your cursors INSENSITIVE, STATIC or FAST_FORWARD, and
stay away from the default keyset cursors.

> and if no what is the alernet solution for that thats what i wanted to
> know....
Rather cursors are the alternate solution when you simply cannot find a
set-based solution. That happens, but it is not that frequent. Here is a
quick example of a set-based solution. Say that you have an employee
table, and you are to update the salaries. Generally there is a two
percent increase, but staff that earns less than 15000 SEK/month gets
300 SEK extra, and all women receive an extra 0.5% raise. This can be
done in one UPDATE:
UPDATE employees
SET salary = 1.02 * salary +
CASE WHEN salary < 15000 THEN 300 ELSE 0 END +
CASE sex WHEN 'K' THEN 1.005 * salary ELSE 0 END
Ah, when I think of it, if you really like iterattion, yes there is now
a new way to do this in SQL 2005, as you now can write stored procedures
in a .Net language such as C#. This gives new oppurtunities to implement
good solutions in SQL Server - and also a lot of new oppurtunities to
implement really poor solutions if implemented improperly.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||> all women receive an extra 0.5% raise. This can be
> done in one UPDATE:
Fine example, but is it legal in any jurisdiction you know of?
As you've mentioned, iteration is a feature of cursors and we do have new
non-cursor features in SQL2005 that are relevant to those types of problem.
The CROSS APPLY operator means we no longer need to use cursors for expandin
g
an adjacency list and similar tasks. Also, the ROW_NUMBER function is a
convenient way to implement sequences over data. So there should be even les
s
reason to use cursors in SQL2005.
David Portas
SQL Server MVP
--|||Yes, cursors are included in SQL 2005. I do not know of any new features of
cursors. They are not the preferred way of doing work (since SQL 7.0), so I
do not use them unless I absolutely have to. This follows MS suggestions and
may be the reason cursors do not change much.
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
"hitendra15@.gmail.com" wrote:

> Is Cursor Included in Yukon/SQL 2005. or any alternet solution for that?
>|||Yes, they have cursors, but if you had been writing good SQL, you would
not be using them more than a few times in 10-20 years of production
coding anyway.|||David Portas (REMOVE_BEFORE_REPLYING_dportas@.acm.org) writes:
> Fine example, but is it legal in any jurisdiction you know of?
Interesting question. If an employer over here would do this, but give the
extra raise to men, there would be one h*ll of a noise. But for women?
My guess, is that they would get away with it. Even more so, if this was
the result of negotiations with the union. Oh, well, wrong newsgroup
I think.

> As you've mentioned, iteration is a feature of cursors and we do have
> new non-cursor features in SQL2005 that are relevant to those types of
> problem. The CROSS APPLY operator means we no longer need to use cursors
> for expanding an adjacency list and similar tasks. Also, the ROW_NUMBER
> function is a convenient way to implement sequences over data. So there
> should be even less reason to use cursors in SQL2005.
Great examples!
Of what I can think of, left is the case when you have a stored procedure
which you want to reuse, and you don't find it worth the effort to
rewrite the stored procedure for handle an input set. And then of course
the few exceptional cases where cursors actually are faster.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||thank you guys i understood that there is a cursor but its not improved
no new features to it,
so it seems me that Procedures, UDT, Functions, triggers etc are Part
of SQL CLR[We can make], cursor is not....am i correct?
Hitendra