Количество строк

← →
alex145 (2004-12-15 12:39) [0]

Я делаю выборку из базы данных при помощи обычного компонента IBQuery. Чтобы узнать количество строк в выборке я использую ф-ию qOrders.RecordCount. Она все время показывает 1. Когда же я подключаю таблицу DBGrid к qOrders то qOrders.RecordCount начинает показывать истинное количество строк. Но таблица отображения мне не нужна. В чем тут ошибка, что я не учел?

← →
Соловьев © (2004-12-15 12:43) [1]

IBQuery.FetchAll;
Но за такое я бы бил:)
Для этого надо юзать еще один запрос с count(*)
или FIBPlus

← →
Val (Alexandria) (2004-12-15 12:44) [2]

qOrders.RecordCount покажет истинное количество строк запроса, если вы полностью отфетчите данные на клиента.

← →
Anatoly Podgoretsky © (2004-12-15 13:04) [3]

Соловьев © (15.12.04 12:43) [1]
В много пользовательской системе count(*) не надежен!

← →
Соловьев © (2004-12-15 13:14) [4]

В рамках одной транзакции или отказаться от колличества. Непонятно для чего это нужно автору.

← →
msguns © (2004-12-15 13:19) [5]

>Anatoly Podgoretsky © (15.12.04 13:04) [3]
>В много пользовательской системе count(*) не надежен!

Не надо так категорично. Хотя в общем случае справедливо.

>Соловьев © (15.12.04 13:14) [4]
>Непонятно для чего это нужно автору.

Ну почему же ? Очень полезно знать кол-во записей в отображаемой таблице. Например, при просмотре счетов, накладных.

← →
Соловьев © (2004-12-15 13:20) [6]

При просмотре? Зачем?
Если нужно проти все записи, то есть Eof
Если нужно пронумеровать, то это и без запроса можно сделать

← →
Anatoly Podgoretsky © (2004-12-15 13:29) [7]

А я как раз про общий случай

← →
msguns © (2004-12-15 13:55) [8]

>Соловьев © (15.12.04 13:20) [6]
>При просмотре? Зачем?

Например при сверке бумажного документа с компьютерным

← →
Соловьев © (2004-12-15 13:56) [9]

Это понятно, но ты же не автор - не будем гадать :)

← →
alex145 (2004-12-15 13:58) [10]

> qOrders.RecordCount покажет истинное количество строк запроса,
> если вы полностью отфетчите данные на клиента

Извините , но я не понимаю о чем речь

← →
Max Zyuzin © (2004-12-15 14:39) [11]

>alex145 (15.12.04 13:58) [10]
Дело в том что InterBase при выполнение запроса типа select * from YourTable не возвращает все записи, а только те что вы чейчас лицезрете перед собой в Grid-е есть команда такая Соловьев © (15.12.04 12:43) [1] вот она как раз и делает то, что высасывает все записи полученые запросом, и потом после нее корректно начинает работать метод RecordCount
Для чего это придумано? Что бы сеть не загружать, все равно человеку одном не просмотреть к примеру 100000 записей за раз... и не зачим их с сервера качать...
Но правильнее получать количество записей в базе способом описанным Соловьев © (15.12.04 12:43) [1]

ЗЫ Всем привет, кто помнит.

← →
Max Zyuzin © (2004-12-15 14:41) [12]

Вах... написал, ошибок то.. аж глаза пестрять, извиняюсь

← →
msguns © (2004-12-15 14:45) [13]

>alex145 (15.12.04 13:58) [10]

При выборке из БД сервер начинает отправку данных по мере их чтения, поэтому НД на клиенте сразу после открытия получает 1 запись или 0 (если нет выбранных). Далее по мере работы сервера данные покачиваются ("подносятся" от англ. слова Fetch) или на жаргоне базовиков "фетчатся". НД не ожидает конца операции, поэтому для того, чтобы "насильно" заставить его принять все записи и таким образом оценить их к-во, требуется воспользоваться методом FetchAll. При достаточно больших размерах НД такая технология приводит к замедлению (подвисанию на некоторое время) приложения, что далеко не всегда может быть удобно. Визуальные компоненты, использующие НД в "многозаписьном" режиме (типа гридов) делают подкачку сами в зависимости от кол-ва отображаемых строк, но не всего набора. Поэтому отображение в гриде датасетов обычно визуально тормозится, особенно для некоторых серверов БД и особенностей работы с этими серверами компонент доступа.
Если Вы не хотите тормозов, но при этом надо знать кол-во записей на момент начала транзакции, в контексте которой происходит выборка, следует воспользоваться не "выкачкой" всех записей (что будет тормозить), а параллельным запросом Select Count(*) обязательно в контексте той же транзакции, что и чтение. При этом для получения точного кол-ва надо в параметнах транзакции указать что-то типа "слепок" (для IB это SnapShot). При этом нет тормозов и Вы получите кол-во записей, соответствующее условиям выборки на момент начала выборки (точнее - старта транзакции).
Вообще, об этом, конечно, много написано в книжках и статьях по базам данных.

← →
Danilka © (2004-12-15 16:13) [14]

[1] Соловьев © (15.12.04 12:43)
Понемногу сталкиваясь с МС-Скулем прихожу к выводу что полный фетч не такая уж и страшная штука. Конечно, при наличии нормального запроса, когда просишь только то, что нужно, а не все разом.

← →
Danilka © (2004-12-15 16:14) [15]

И даже больше, засосал все и закрыл транзакцию. :)

>Danilka © (15.12.04 16:14) [15]
АФАИР при закрытии транзакции у тебя заодно и все датасеты закроются к ней относящиеся, IBQuery помоему точно.

← →
alex145 (2004-12-15 19:01) [17]

Всем огромное спасибо, такого подробного обьяснения даже в книжках не дают :)

[16] Max Zyuzin © (15.12.04 16:19)
Дык, их можно утянуть в КлиентДатасет или еще что-нибудь подобное, например в MemTableEh из эхлиба. :)
Просто, поработал с МС-Скулем и АДО - удобно, когда все что попросил на клиенте, главное не зарывацца и не просить много. :)

FetchAll и Count(*) взаимо исключаемые вещи. Если нужно закачать все записи только чтобы узнать их колличество, то это абсурд. Для подсчета нужно делать отдельный запрос. И мс-куль, адо не суть важно, а подход. Клиент не резиновый и ОП у него как правило мало. Да трафик нефиг перегружать. Конечно речь идет не про детские базы, а про серезные.

[19] Соловьев © (16.12.04 10:30)
Дык, я и говорю про подход. Я не говорил, что фетч всего только лишь для определения кол-ва записей.
И базы вовсе не детские, однако на любых здоровенных базах клиенту не нужны все записи сразу, а по каким-то условиям. Если это док-ты, то, как правило, за какой-то период, например месяц, или когда их очень много - период по-умолчанию - день. Если справочники большие - то делим на группу/подгруппу или еще как.
Просто, мне все больше нравится именно такой подход - закачал то что нужно и отрубился. Чем именно нравицца - точно сказать не могу пока, чисто субьективно. :))

[21] Соловьев © (16.12.04 10:43)
Тогда, можно сказать что Марко Кэнту тоже не прав. Он в книге по Д7, кажись когда расписывает преимущества DBExpress (или когда про АДО, не помню уже) тоже пишет что это хороший подход - переход от серверного курсора к клиентскому. :))
Впрочем, история рассудит. Или просто наберусь опыта с клиентским курсором и расскажу. :))

Количество строк Найти похожие ветки