2008/9/30 Fulvio Senore <mailing@...>:

>
> Daniel Albuschat ha scritto:
>
>> So I am interested in:
>>
>> a) How many Firebird-users are developing using Qt (either C++ or Jambi)?
>>
> Not me.
>> b) What other languages and toolkits are popular among Firebird-users?
>>
>>
> I am using C++ with wxWidgets.

Thanks, you're the first to actually answer my question. ;-)

> A question: if you are using QT only for threads support, why not use
> the Boost implementation of threads? The resulting code should be more
> portable.

I'm using Qt's thread-safe "Queued Connection" variant of the
signal/slot mechanism.
This makes this very easy and stable. Queued Connections basically
work like that:
You send a request (aka emit a signal) that's connected to the thread-object.
The thread-object has an internal event-loop that waits for signals
and calls the
corresponding slot (worker function).

This lifts a lot of problems and work from my shoulders. We're
internally using Qt anyways, and this project's primary objective is
to make it usable for our applications. Making it available to the
Firebird community is a big plus, though.

> It looks like you like the idea of knowing how many rows are there in
> the result set of a query. This might be useful in some situation, but
> it comes at a possibly high price: you always retrieve all the rows from
> the server. This might increase a lot the server load.

This is not necessarily true. You have to distinguish two kinds of
load on the server:
The CPU load and the storage (hard-disk) load. The CPU-load is high
while preparing
a statement. The preparation is constant no matter how many rows I'll
finally fetch.
Fetching all rows from the prepared statement does not significantly
increase the
CPU-load, but the storage-load. There's an important thing to know
here: I'm fetching
only the primary keys from a result set to know how many rows there
are and which
primary key the row at the temporary "index" in my table has.
I believe (I'm not completely certain, though) that fetching only the
primary keys keeps
the server load relatively low.
Only when displaying a dataset in the table, the complete data is fetched.

Perhaps someone with more founded knowledge of how Firebird works can
share their opinion on this topic?

> When presenting data in a grid users usually scroll the grid only a few
> time. If they start a query that returns some hundred thousands rows
> they scroll a few times, then they realize that they will never find
> what they are looking for and they start a more specific query that will
> return only a few rows.

That's completely true. No-one will look through more than 100 or 1.000
datasets. But what is important is the "feeling" the user gets when using
one of the - in my opionion awkward - other solutions for presenting data
to them. I want them to think that all the data is there, just waiting for
them, while not blocking further interaction with the program.

> Always retrieving all the rows from the server looks overkill in such a
> situation.
>
> Yes I know: only dumb users work this way, but it looks like there are
> many of them...

Definitely. I don't call them dumb, though. They just have their expertise in
a different field than we have. :-)

Thanks for your reply,

Daniel Albuschat

--
eat(this); // delicious suicide