Курсор Oracle обеспечивает последовательный доступ только в одном направлении (несмотря на скроллируемость резервного набора).
Поэтоу предложенный метод пройти до конца, а потом вернуться в начало приведет только к повторному выполнению запроса и перебору всех строк, но скрытым образом.
То есть сначала все строки извлекаются на клиента, а потом выполняется повторно запрос и в полученном НОВОМ наборе курсор устанавливается в начало.
Если уж так хочется узнать количество строк, перед основным запросом выполни SELECT COUNT(*) FROM ... WHERE "условие"
где "условие" точно такое как в основном запросе.
Все таки будет меньший напряг для системы.

to stdio
Ну, и как это противоречит тому, что я написал ?
Когда ты вызвал execute(), выполнился парсинг SQL и было произведено его выполнение.
Указатель курсора установлен на начало для выборки.
Когда ты вызвал rs.last() все строчки должны быть "профетчены" на клиента, что естественно потребовало массу работы.
В чем ошибочность моих слов ?
Проблема этого дела в том, что не пройдя весь курсор с фетчем до конца ты не узнаешь, сколько возвращено строк.
Это принципиальный вопрос, так как узнать количество строк в Oracle можно только перебрав их все.
Вернуться в начало - значит повторно выполнить запрос.
Чем тебе не нравиться COUNT(*). Запрос, конечно все равно выполняется, но хоть фетч уменьщается до одной строки.
И дело тут не в версии драйвера, а в механизме работы курсора Oracle.

Уел !
Ну да, я не обратил внимания на то, что у тебя в примере результирующий набор TYPE_SCROLL_INSENSITIVE.
И в этом моя ошибка.
Однако при чувствительном к изменениям наборе запрос все-равно будет выполняться повторно.
С другой стороны большой, наверное, кайф выбрать тысячи строк на клиента только для того, чтобы выяснить сколько строк на самом деле будет выбрано.
Таким образом задача stdio видимо состояла не в том, чтобы ответить на вопрос, как без выполнения операции фетч выяснить - сколько строк вернет запрос, а в том чтобы уличить меня в ошибке.
Ты победил !

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

Извините за назойливость. Маленькое дополнение
У меня есть небольшая универсальная программа по выполнению запросов и выводу результатов написанная на Java.
В ней запрос (Oracle 10g )

SELECT * FROM dba_objects;

возвратил строк : 48259 За время : 12344 м-сек.

Запрос

SELECT COUNT(*) FROM dba_objects;

возвратил строк : 1 За время : 203 м-сек.

Правда это с учетом вывода на экран. Однако, согласитесь, разница во времени существенная.
Поскольку я принципиально не использую чувствительных к скроллированию курсоров, потребность в памяти при десятках подряд выполняемых запросов составляет 12М и не больше.
Что касается скроллируемых наборов, то предпочитаю собственного изготовления RowSet с кэшированием строк в базе, расположенной на сервере приложений.

Господа, обращаю ваше внимание на некоторые дополнительные аспекты.

1. То, что для изменения строки, еще в момент выполнения операции POST и в момент ее блокирования необходимо кэширование ROWID, это несомненно, как несомненно и то, что драйвер обязан это делать.

2. Однако, рассмотрим следующую ситуацию. Пользователь работает с последними строками резервного набора, а в это время администратор удаляет одну из первых строк и вставляет ее вновь. При этом он еще вставляет десяток строк (одна из них может получить то же самое ROWID). Можете ли Вы гарантировать, что по ROWID будет получена та же строка, когда пользователь вернется в начало набора ? Фиксация ROWID ведь гарантирована только при блокировании строки. Представьте себе - пользователь проскроллировал набор в начало увидел на месте старой строки нечто совершенно неожиданное, так как ROWID старой строки получила другая.

3. Ситуация практически та же, но запрос обращается к секционированной таблице, а администратор выполняет операции MERGE PARTITION или SPLIT PARTITION.
Можно было бы привести и другие примеры, но думаю и этого достаточно.

4. Откровенно говоря менторский тон stdio мне надоел, и с Вашего разрешения, я в дискуссию по этому топику больше вмешиваться не буду. Пусть последнее слово останется за ним.

to Ааз

Не хотелось к этому неприятному разговору обращаться вновь, но раз затронули...
приведу мое личное мнение о данном топике.

1. stdio, конечно подправил мое личное представление о резервном наборе драйвера Oracle. Будь это сделано доброжелательно, как обычно бывает в разговоре коллег, я бы сказал ему спасибо. Однако его задачей являлось не обсуждение поставленного вопроса (по этому вопросу он отправил меня в баню), он вовсе не желал доброжелательно подсказать мне, что я не прав, а хотел показать - как он умен (стандартный ввод/вывод : не больше и не меньше), а это знаете ли раздражает. Не думайте, что я настолько глуп, чтобы не уловить подтекст.

2. stdio даже не попытался резюмировать итоги "дискуссии", он просто откровенно посмеивался над человеком, которого вовсе не знает, причем кое-где с использованием откровенного передергивания (если Вы внимательно читали топик).
А ведь итоги дискуссии интересны сами по себе !

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

- Обновляемый и скроллируемый резервный набор выполняет таки повторные запросы. Кстати в топике я не мог отрицать, что ROWID извлекается, так как об этом явно имеется слайд в курсе. Я лишь отрицал (как выяснилось напрасно), что повторные запросы базируются на ROWID. Базирование на ROWID, казалось дает в этом смысле преимущества, однако может приводить к появлению коллизий, тем более что скроллируемый резервный набор имеет массу и других ограничений. Возможно из-за неудовлетворенности положением дел и появилась концепция RowSet, решение которой фирмой Sun в ее интерфейсах, на мой взгляд, также далеко от совершенства.

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

4. Являясь преподавателем с двадцатилетним стажем и зная, что эффект желания поучать является профессиональной болезнью, стараюсь всячески избегать этого порока. Более того, стараюсь без обид признавать ошибки и принимаю с благодарностью помощь в искоренении ошибок от кого бы то ни было. Горжусь тем, что будучи в свое время, начальником отдела на заводе не боялся просить у рабочих помощи, когда чего-то не знал. Общение с stdio для меня - еще один урок в том смысле, что я ни при каких не должен поступать подобным образом.

4. И если уж на то дошло дело до ссылок на регалии - к.т.н, доцент, (Oracle8/8i/9i OCP DBA), (Oracle8/8i/9i OCP Developer), Sun certified Java programmer.