2008/9/30 Daniel Albuschat <d.albuschat@...>:

> 2008/9/30 Milan Babuskov <milanb@...>:
>> Daniel Albuschat wrote:
>>> - None I have seen so far give an indication of how many datasets
>>> exist in the result set (i.e. by sizing the scroll-bar appropriately).
>>
>> I'd rather use the word 'records' because 'dataset' means the same thing
>> as 'result set'.
>>
>>> Even database-managers that should be very sophisticated in this task,
>>> often fail in this regard.
>>
>> This is because 'select count()' is slow in most cases. There is no way
>> to know about row number efficiently.
>
> Yes, exactly. It's physically impossible. That's why most people
> either think "Ok, so the user has to wait for [incredibly long
> timespan], I can do nothing about it" or "Well, it'll take too long.
> The user will not know how many records there are".
> My solution, however, is to let the user go on with his work with the
> program while it is fetching all available records in the background.
> Without the application-developer doing anything fancy for this.

Ah, and by the way. I implemented a second optimization to speed the
whole thing up. There are two sql-statements/cursors/whatever you call
them that fetch from the database. The first looks like "select id
from table" and selects only the primary keys. The second fetches the
needed data only when it is about to be displayed. This is, as far as
I know, commonly used in many GUI-libraries anyways.
The really "new" technology I'm describing here is the asynchronous
and parallel processing which is usually impossible due to missing
thread-safety of the firebird client-library.

--
eat(this); // delicious suicide