Нужно узнать объем выборки "в процессе"

Нужно узнать число записей, возвращаемых Select. До того, как данные этого select-а будут все закачены. Очень хотелось бы, чтобы число записей присутствовало сразу, в первой записи, чтобы можно было перед фетчем остальных записей принять решение о дальнейших действиях.

Ну, вот такая конструкция придумалась:

select -count(id) from MyTable union all select id from MyTable order by 1

Вернет ли этот запрос гарантированно ожидаемое число записей в первой прочитанной записи, независимо от праметров транзакции, в многопользовательской среде?

Или что-то попроще, побыстрее и поумнее можно придумать?

1. Обязательно знать СУБД. Для различных СУБД поведение запроса может быть различным (в зависимости от способа работы с тразакцией).

2. В общем случае

select -count(id), OTHER FIELDS from MyTable where_clause_1 union all select id, OTHER FIELDS from MyTable where_clause_2 order by 1

где where_clause_1 = where_clause_2 должно вернуть то, что ожидается - количество данных.
Но!: это в снапшоте.

P.S. Есть еще много неназванных мной нюансов: например, подзапросы, ХП и т.д.

Гаджимурадов Рустам

1. Обязательно знать СУБД. Для различных СУБД поведение запроса может быть различным (в зависимости от способа работы с тразакцией).

Тьфу млин - не заметил, что ты в форуме IB вопрос задал. :) Сорри. Но все равно версию сервера знать надо.

При RC транзакции можешь получить не то, что хотел. При снапшоте все должно быть правильно.

Короче говоря, если хорошо понимаешь разницу между снапшот и RC
(и нюансов, возникающих при работе с ним), то проблем быть не должно.

P.S. По поводу самого запроса - он все-таки такой вот простейший или там учатсвуют ХП, подзапросы и т.д.?

1. Структура семантически подобна приведенному.
2. Бех ХП.
3. При снапшоте не интересно. Если только в снапшот - то нет никакого смысла громоздить union, проще два отдельных запроса сделать.

Жаль. Я почему-то был уверен, что если в рамках одного SQL запроса - то данные будут логически целостными.

Спасибо.

Поэкспериментирую-ка я с утра. Что-то мне не верится, что все так плохо. И доки почитаю.

Ну почему же плохо? Нормально. При RC и без подзапросов и прочей лабуды все будет в ажуре.

P.S. Единственное - особенности RC могут себя проявить.

mv

Я почему-то был уверен, что если в рамках одного SQL запроса - то данные будут логически целостными.

Ты именно про фетч думаешь? Да нет, с фетчем записей все как раз в порядке.
Данные возвратятся те, которые были актуальны на момент старта запроса.

Единственно - постольку поскольку union это фактически набор подзапросов,
то на момент начала второго "запроса" (выбор самих данных) данные могут измениться.

И я думаю считано будет новое, более актуальное состояние. Но есть еще no_rec_version.
Впрочем для полной уверенности в реализации нужно узанть у самих разработчиков.

Ну, почему же Гуру молчат?

Вернет ли этот запрос гарантированно ожидаемое число записей в первой прочитанной записи, независимо от праметров транзакции, в многопользовательской среде?

Я вот не смог "сломать" ожидаемого поведения. А что на самом деле?

mv

Ну, почему же Гуру молчат?

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

Я вот не смог "сломать" ожидаемого поведения. А что на самом деле?

Смотря что считать ожидаемым и смотря как стараться. Зависит от соотношения объёма выборки и интенсивности коммитов изменений.