Использование курсоров в приложениях под I-нет

Николай
Дата: 12.02.2001 17:50:30
Приветствую!
Может быть кто знает, есть ли необходимость килять созданный курсор, если известно, что, например, GLOBAL курсоры существуют лишь до закрытия текущего соединения? Так ли это? Удалятся ли созданные интернет-пользователем курсоры
из БД при простом уходе его со странички?

И второй вопрос: как создать блочный курсор (чтобы можно было выдать сразу несколько записей)?
Помогите, я буду очень признателен!
VadimB
Дата: 13.02.2001 14:46:25
А приложениях под I-нет лучше избегать использование курсоров.
Если опишешь задачу, тогда что нибудь придумаем
Николай
Дата: 14.02.2001 10:29:59
ПОЧЕМУ следует избегать использования курсоров?
А задача состоит в том, чтобы STOREDPROC выдавала общее кол-во книг по запросу, а выдавала клиенту лишь часть (например 20). Исходя из соображений скорости ответа и загрузки сети я пришел к выводу, что необходимо передавать клиенту лишь часть запроса. Как это лучше сделать?
VadimB
Дата: 14.02.2001 12:50:57
Пусть есть таблица с книгами Book (BookID,BookName)
Для выдачи по 20 книг отсортированных по именам создаем SP:
create procedure BookGet @BookName varchar(250) as
select top 20 * from Book where BookName>@BookName order by BookName

Выдача первых 20 книг: exec BookGet @BookName=''
Выдача очередных 20 книг: exec BookGet @BookName=@Name
где @Name имя 20 книги из предыдущего запроса.
Это имя можно хранить в невидимом поле на html
Николай
Дата: 14.02.2001 14:54:09
Классно!!!
Но: как в таком случае переходить на, скажем 20 записей назад?
Или релизовать независимые переходы (как, например, в Рамблере):
0 - 20 21 - 40 41 - 60...
Наверное, от этого придется отказаться?
VadimB
Дата: 14.02.2001 15:45:19
Вариант длля случая, если нужно получить строки с 200 по 235
КОТОРЫЕ ОТСОРТИРОВАННЫ ПО УНИКАЛЬНЫМ КЛЮЧАМ.
declare @StartRecord int
declare @RecordInPage int
declare @MaxKey varchar(255)

-- строки с 200 по 235
set @StartRecord=200
set @RecordInPage=35

set rowcount @StartRecord
select @MaxKey= max(UK) from T order by UK -- нати максимальный уникальный ключ для первых @StartRecord записей
set rowcount 0

set rowcount @RecordInPage
select * from T where UK > @MaxKey order by UK -- выдать @RecordInPage записей, пропустив первые @StartRecord записей
set rowcount 0
Николай
Дата: 14.02.2001 16:27:00
Ну, что же, похоже дошли до истины!
СПАСИБО!!!
Alexander Rudenko
Дата: 14.02.2001 19:23:54
Встречный вопрос:
а если мне нужно сортировать по разным полям. Например, по году издания. Ведь их может быть много (книг с одним годом). Как быть в таком случае.

Текущая идея - создать уникальный составной ключ вроде еще одного вычисляемого поля и нагло прописать его в таблицу. Но мне эта идея не очень нравиться.
alexeyvg
Дата: 15.02.2001 12:03:11
Если нужно сортировать по разным полям то идея создать уникальный составной ключ - это правильно, хороший метод.
Если условия сортировки меняются - нужно создавать промежуточную временную таблицу, вливаь в неё данные с сортировкой, а затем использовать вышеприведённую выборку.
Это будет намного быстрее и надёжнее курсоров. Используйте курсор, только если вам надо для каждой строки вызывать много хранимых процедур!
qu-qu
Дата: 15.02.2001 13:01:46
> Это будет намного быстрее и надёжнее курсоров. Используйте курсор, только если вам надо для каждой строки вызывать много хранимых процедур!

Золотые слова...
Например, в MS SQL 6.0 курсоры оставались в памяти и засирали ее ДАЖЕ при явном указании команды на их закрытие по окончании процедуры (поторопились тогда, видимо, "мелкомягкие" реализовать серверные курсоры и оставили их в "сыром" виде). С тех пор у меня к серверным курсорам отношение настороженное - чем меньше их, тем лучше... (кстати, за 4 года работы с 3-мя последовательными версиями MS SQL только 1 раз мне пришлось использовать курсор, к счастью это было уже под версией 7.0, а до этого прекрасно обходился временными таблицами, даже простое "сканирование" результатов выборки в режиме ForwardOnly делал на временных таблицах).