Никогда не понимал в чем смысл динамических курсоров. Намного проще и надежнее делать отдельные запросы с малым количеством возвращаемых строк.



Но если очень хочется, то смотри в сторону "закладок". В теории, это работает так:
Когда ты еще только создаешь клиентский курсор, ставишь ему атрибут SQL_ATTR_USE_BOOKMARK. Потом уже посылаешь свое "select * from table". Тогда у курсора в нулевой колонке будет хранится уникальное значение (сгенерированное самим ODBC). Ты сможешь его читать через SQLGetData(stmt, 0, ....). А уже зная какой уникальный номер получила та или иная строка курсора, можно будет на них быстро прыгать через SQLFetchScroll(SQL_FETCH_BOOKMARK).
И нет, задать самому чтобы закладка равнялась полю ID нельзя. Тебе придется сначала пробежать по всему курсору и составить словарь "#закладки<=>ID".
Сам я такое извращение не делал, так что тонкостей не расскажу.

Да и работать это будет далеко не везде. Не все СУБД позволяют свободное хождение по курсору. А те которые позволяют, часто оставляют в DNS возможность запрета таких курсоров. Так что ты сильно рискуешь...

RedCatXWhite OwlНамного проще и надежнее делать отдельные запросы с малым количеством возвращаемых строк.
Увы, но SQL не предоставляет возможности передвигаться по всей таблице с помощью функций вида GetNext/GetPrev иначе как с помощью курсора... Нет ни одной задачи которая требовала бы передвигаться по всей таблице.
Вообще, нет таких задач на свете.
Все что нужно, прекрасно и более надежно решается через "select ... where id=?" и "update ... where id=?".

Клиентские курсоры это изначально дурная идея. С точки зрения клиента это плохо потому что ненадежно. Сеть глюканула - курсор поломался, все что пользователь изменял в этом курсоре ухнуло в никуда. А с точки зрения сервера, такие курсоры требуют долгоживущих транзакций, что в свою очередь может привести к коллизиям, либо потребует выключения изоляции. Что в обоих случаях хреново.

RedCatXНо однако, SQL хранит таблицы ключей, неужели к ним никак нельзя получить доступ в пределах курсора?Можно конечно. SQLGetData(stmt, номер_колонки_с_ключом, ...).

onstat-RedCatXДоброго времени суток!

Возникла такая проблема: я создаю динамический курсор по запросу вида "SELECT * FROM table ORDER BY col_name, id", и мне нужно установить курсор на строку, где id (первичный ключ) равен N. Извлечь эту строку сразу ("SELECT ... WHERE id = N") невозможно, так как нужно сохранить возможность перемещаться назад-вперед по всей таблице, просто начальной позицией нужно сделать определенную строку как я писал выше. Возможно ли это реализовать с помощью ODBC?
Заранее спасибо!

это офтопик
опция называется
Scrollable cursorsDECLARE cursor_name sensitivity SCROLL CURSOR FOR SELECT ... FROM ...

и поддерживается всеми СУБД.

Вероятнее всего в ODBC не поддерживатеся.Ты путаешь серверные курсоры и клиентские.
Те о которых ту думаешь это серверные, и они действительно офтопик (и кстати далеко не все СУБД умеют делать SCROLL курсоры).

А клиентские курсоры о которых говорит RedCatX это совершенно отдельный вид курсора, практически разделенный на две части - один виртуальный курсор на сервере, а все управление и fetch из него делается на клиенте. Эти курсоры тоже могут быть как одно-направленными, так и свободно бегающими. И это тоже зависит от СУБД и поддерживается не везде.

RedCatXDimitry Sibiryakovпропущено...

Тогда не парься с курсорами, а тупо вычитывай результат запроса в массив и уже в нём
навигуйся хоть до позеленения.


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