2 Slava
> плюс возможность перемещаться по данным.

Вы полагаете это плюс!?

2 Slava
Тогда другой вопрос, почему Вы считаете, что 100% не минус?

Работа реляционных СУБД построена на реляционной теории (естественно), т. е. на работе с данными как множествами а не построчно (это к вопросу о математике).
Поэтому на практике курсор - это тормоз в работе и пожиратель ресурсов, используется всегда в самых крайних случаях, когда функциональность по другому реализовать не получается. Такие случае крайне редки.

Если непонятно изложил, спросите у SergSuper он Вам точно объяснит

>Боюсь что для Вас курсоры будут как это соглашение
Я обхохотался класс!

2 Raimund

А мой совет не слушать советы Slava, зачем Вам проблемы на Вашу голову?

2 Slava

Интересно сколько юзеров юзают Вашу базу, и не ходят ли они пообедать, ожидая выполнения очередного запроса?

P.S. Давно однако так не смеялся

Ладно, Slava, простите, и не обижайтесь
Просто мне показалось, что круть начали показывать Вы.
А мой совет, впрочем как и многих на этом форуме, отказывайтесь от курсоров, везде где это можно.

А решение уже предложил SergSuper у меня круче нет

2 Raimund

Если много вложенных позапросов, то лучше всего поискать несколько решений, возможно и с курсорами и с временными таблицами, а потом сравнить, что работает быстрее, вряд ли это будут решения основанные на курсорах.

До чего ж Вы упрямы в своем невежестве, Slava.
Вас BOL, устроит?

Do not use cursors more than necessary.
Cursors are a useful tool in relational databases; however, it is almost always more expensive to use a cursor than to use a set-oriented SQL statement to accomplish a task.

In set-oriented SQL statements, the client application tells the server to update the set of records that meet specified criteria. The server figures out how to accomplish the update as a single unit of work. When updating through a cursor, the client application requires the server to maintain row locks or version information for every row, just in case the client asks to update the row after it has been fetched.

Also, using a cursor implies that the server is maintaining client state information, such as the user's current rowset at the server, usually in temporary storage. Maintaining this state for a large number of clients is an expensive use of server resources. A better strategy with a relational database is for the client application to get in and out quickly, maintaining no client state at the server between calls. Set-oriented SQL statements support this strategy.

However, if the query uses cursors, determine if the cursor query could be written more efficiently either by using a more-efficient cursor type, such as fast forward-only, or a single query. For more information, see Optimizing Application Performance Using Efficient Data Retrieval.

Хотите проверить правильность рекомендаций от Microsoft, проверяйте, я не собираюсь более доказывать Вам очивидные вещи.

2 SergSuper
>SergSuper предложил не самое красивое решение. Не хочу показаться "крутым", но меня оно наверно!!! бы не устроило.

Каково?!

2 Slava

Скажу вам по секрету, лично я не стал бы учить SergSuper красивым решениям

Ладно, Slava давайте без обид, ОК?

>Не надо обвинять кого-либо в невежестве так мимоходом.
>"Не судите сами, да не судимы будете"

Еще раз прошу прощения, погорячился.

>Не надо ссориться, горячие финские паарни.