Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2003.09.15;
Скачать: CL | DM;

Вниз

Общий count...   Найти похожие ветки 

 
mOOx_ ©   (2003-08-23 14:34) [0]

Поясняю: есть класс а в нем процедура, в которую я передаю запрос. В ней заполняются поля этого самого класса, в том числе и count. Класс писался, когда в базе было макс. 400 записей. Поскольку свойство RecordCount в TIBQuery работает криво, то определение Count"а я делал так, Next до конца набора и Count:=RecordCount :). Когда я опробовал этот класс для того, чтобы достать 40000 записей, то просто за..... ждать. Значит вопрос в следующем: корректно ли для определения count"а вырезать из запроса все между select и from и вставлять на это место count(*)? При этом надо учесть, что запрос может быть давольно сложным :), возможны не только выборки из нескольких таблиц, но и вложенные запросы.


 
kaif ©   (2003-08-23 14:42) [1]

В принципе проблем не вижу. Должно работать. Почему бы нет?
Я еще не разу не сталкивался с проблемой того, чтобы нельзя было заменить возвращаемый набор полей на просто count(*). Если конечно, в запросе нет GROUP BY. Как известно, GROUP BY потребует перечисления того же набора неагрегатных полей после SELECT. Но я думаю, у тебя не тот случай. Удали еще из запроса ORDER BY, если такое там присуствует.


 
Vorobyev Sergey   (2003-08-23 14:43) [2]


> Поскольку свойство RecordCount в TIBQuery работает криво

Оно не работает криво, просто TIBQuery отбирает не все записи,
и чтобы RecordCount вернул все записи надо:
IBQuery1.FetchAll;
n := IBQuery.RecordCount



> корректно ли для определения count"а вырезать из запроса
> все между select и from и вставлять на это место count(*)?

Не корректно..
Для каждого запроса по разному.. Здесь нужен специальный анализатор (парсер), который бы для ЛЮБОГО запроса составлял запрос для подсчета количества записей.. Честно говоря, я такого анализатора не встречал, да и боюсь его невозможно создать из-за того, что даже вручную не для любого запроса можно создать такой..


 
kaif ©   (2003-08-23 14:44) [3]

И еще. Если в запросе возможен UNION, то идея работать не будет. Или же надо будет везде после SELECT вставлять COUNT(*), а потом на клиенте еще раз суммировать результат.


 
kaif ©   (2003-08-23 14:46) [4]

2 Vorobyev Sergey (23.08.03 14:43) [2]
Ты можешь привести пример, когда нельзя так поступить?
(без GROUP BY и ORDER BY)


 
Vorobyev Sergey   (2003-08-23 14:50) [5]


> Ты можешь привести пример, когда нельзя так поступить?
> (без GROUP BY и ORDER BY)

Пример, не могу..
Я только предполагаю, это гипотеза если хотите.. (я же написал ".. боюсь его невозможно создать..")

Но можно объявить конкурс: "Кто составит запрос, к которому нельзя будет составить запрос на подсчет количества записей"


 
mOOx_ ©   (2003-08-23 15:03) [6]

Отличная идея про конкурс :). Буду думать. А свой способ я всетаки попробую потестить. Вообщем то пока запросы не такие уж и сложные (по крайней мере нет union и order). Если найду проблему - сразу отпишу. А вообще спасибо за заботу о ближнем :)



Страницы: 1 вся ветка

Текущий архив: 2003.09.15;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.031 c
1-48553
Хозявин М
2003-09-01 07:20
2003.09.15
О разработке нового компонента


1-48576
KSergey
2003-09-04 09:43
2003.09.15
Динамический массив и TObjectList


14-48749
Knight
2003-08-26 08:06
2003.09.15
Miranda рулит...


1-48540
dez
2003-09-02 11:42
2003.09.15
Abstract Error


14-48686
Vlad Oshin
2003-08-27 15:57
2003.09.15
Rouse_, понапиши перлов что ли...