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

Вниз

количество записей в IBQuery?   Найти похожие ветки 

 
AlexanderSK   (2004-04-12 17:16) [0]

Выполняю запрос - IBQuery.Open
Смотрю количество полученых записей - IBQuery.RecordCount
Получаю "1"
Начинаю перебирать записи через First/Next их оказывается больше!

Подскажите, пожалуйста, в чем тут дело? И как с этим бороться?


 
Vlad ©   (2004-04-12 17:18) [1]


> AlexanderSK   (12.04.04 17:16)  

Для начала FetchAll или Last, а потом RecordCount


 
Johnmen ©   (2004-04-12 17:19) [2]

Не все записи переданы на клиента.
Принудительно - FetchAll.
Но работать опираясь на RecordCount в данном случае идеологически неверно...


 
AlexanderSK   (2004-04-12 17:26) [3]

>Johnmen ©  (12.04.04 17:19) [2]
а как тогда правильнее?


 
Johnmen ©   (2004-04-12 17:28) [4]

>AlexanderSK   (12.04.04 17:26) [3]

Смотря что надо...


 
AlexandserSK   (2004-04-12 17:32) [5]

>Johnmen ©  (12.04.04 17:28) [4]

Выполняем запрос. Далее если результат - одна запись ее и берем! А если несколько записей - тогда еще по ряду критериев выбираем опять же одну запись!


 
serge35   (2004-04-12 17:32) [6]

FetchAll - это правильно!.


 
Johnmen ©   (2004-04-12 17:40) [7]

>AlexandserSK   (12.04.04 17:32) [5]

Не очень понятна цель таких манипуляций...

>serge35   (12.04.04 17:32) [6]
>FetchAll - это правильно!.

На sql.ru один деятель тоже так считает. Но никак не может понять, почему же ему приходится больше 1 часа (!!!) ждать отфечивания 4 млн записей.... :)
Кстати, так и не дождавшись...


 
Vlad ©   (2004-04-12 17:56) [8]

Не, ну если у автора стоит вопрос между одной или несколькими записями, то FetchAll поможет, однако действительно, непонятна цель такой странной выборки...


 
Vemer ©   (2004-04-19 09:38) [9]

Если интересует количество записей, можно запрос с группировкой и Count() переделать попробовать. Хотя зависит от задачи.


 
Koba   (2004-04-20 18:30) [10]

Выполняеш SQL-запрос select count(*) from xxx
и kol:longint
 kol:=query1.fields[0].asinteger
но потом не забудь выполнить запрос select * from xxx


 
Vlad ©   (2004-04-20 18:33) [11]


> Koba   (20.04.04 18:30) [10]

Это не есть хорошо.


 
kaif ©   (2004-04-20 18:55) [12]

Ну почему FetchAll неправильно? Допустим, разработчик заранее знает, чтозаписей в этом наборе не более пары сотен. Предположим, это строки какого-нибудь инвойса. А далее, допустим, разработчих хочет экспортировать эти строки куда-нибудь в Excel или еще куда... И хочет ProgressBar прикрутить. Почему бы не сделать FetchAll и не присвоить:
 ProgressBar.Max := IBQuery.RecordCount
Предположим, что время отфетчивания раз в 10 меньше времени экспорта. Тогда это имеет смысл сделать. А не вызывать еще дополнительный агрегатный запрос, который все равно ту же информацию должен выдать.


 
Sergey Masloff   (2004-04-20 21:24) [13]

kaif ©   (20.04.04 18:55) [12]
>Ну почему FetchAll неправильно? Допустим, разработчик заранее >знает, чтозаписей в этом наборе не более пары сотен. >Предположим, это строки какого-нибудь инвойса.
Ну то есть ты думаешь в инвойсе не может быть более пары сотен строк? Десятки тысяч могут быть легко ;-) Лучше конечно не полагаться на то что разработчик "знает" заранее. Хотя конечно иногда прикинуть это число можно с достаточно большой долей уверенности.


 
kaif ©   (2004-04-21 00:45) [14]

2 Sergey Masloff   (20.04.04 21:24) [13]
 Нет, ну если я пишу программу под названием InvoiceMaker и ее хрен знает кто покупает по всему земному шару, тогда может в один пасмурный придет дядя в черном плаще и скажет, что в его инвойсе всего ср#ных три миллиона строк, а моя программа, которую он купил за $50 этот инвойс долго фетчит, проклятая!
 Тогда я сниму шляпу - и верну чуваку его $50.
 :)


 
Sergey_Masloff   (2004-04-21 09:08) [15]

kaif ©   (21.04.04 00:45) [14]
>Тогда я сниму шляпу - и верну чуваку его $50.
В корне неверный подход ;-) Клиента, как говорит один мой знакомый официант, надо ласкать. Если у него 3 млн. строк инвойсы то может под него можно внести пару изменений и глядишь не ты ему 50$ а он тебе инвойсик оплатит переводом на твой эккаунт 50K$ и договор о долгосрочном сотрудничестве. Нет, серьезно.
 Кстати посмотрел я твою Allegro. Молодец, симпатично получается. Так что желаю успехов в развитии и откусить кусочек рынка!


 
Johnmen ©   (2004-04-21 09:27) [16]

>kaif ©   (20.04.04 18:55) [12]
>Ну почему FetchAll неправильно?
>Допустим, ...
>Предположим, ...
>..., допустим, ...
>Почему бы не сделать ...
>Предположим, ...

:)

В том и дело, что применимость FA зависит от некоторых условий.
Но мы же не хотим, чтобы на поведение нашего приложения влияли внешние факторы. Исходящие к тому же от пользователя ? Я думаю, что нет. Тогда мы не должны учитывать и опираться на всякие "если" и "возможно". Т.е. не делать FA.


 
kaif ©   (2004-04-21 10:52) [17]

2 Sergey_Masloff   (21.04.04 09:08) [15]

Спасибо! :)

2 Johnmen ©   (21.04.04 09:27) [16]

 И все таки я бы сделал исключение для справочников. По вашей логике получается, что и DBLookupComboBox-ы нельзя использовать и даже сетки. Мало ли? А вдруг там миллиард записей? Например в справочнике "Страны". А кто его знает? Мало ли что может быть... Мы же должны каждый день готовиться к ядерной войне. Следовательно, если справочник "страны" доступен пользователю для редактирования, то ни грид, ни комбо-бокс давать ему нельзя! Потому что если он внесет миллиард стран и случайно потянет ползунок, то фетчиться будет долго...
 :)


 
Johnmen ©   (2004-04-21 11:21) [18]

>kaif ©   (21.04.04 10:52) [17]

Да, конечно. Разумное применение и ограничение должно присутствовать...
Просто применение или неприменение FA зависит от данных конкретных, я бы даже сказал, сущностных и смысловых, факторов...
А таковые отсутствовали в вопросе автора.
:)



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

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

Наверх




Память: 0.51 MB
Время: 0.035 c
7-1080573409
TankMan
2004-03-29 19:16
2004.05.16
Как узнать высоту заголовка окон?


14-1082751584
Andy BitOff
2004-04-24 00:19
2004.05.16
А когда и кто (если не секрет) смотрит почту на adm@delphimaster.


14-1082696455
V.exeR
2004-04-23 09:00
2004.05.16
"Улица ремесел"


1-1083437406
G-ray
2004-05-01 22:50
2004.05.16
Подсветка синтаксиса


4-1080451471
C.A.M.
2004-03-28 09:24
2004.05.16
Восстановление сетевого подключения