Lee Jenkins wrote:

>Anyway, I asked that he use a Query (IBO, FIB, even IBXQuery) type component
>to access our Firebird database. He asked why and I tried to explain to him
>how query components are better since they pull only a subset of the table
>over the wire, how I see numerous developers on the Firebird lists porting
>Desktop DB based apps over to Firebird and having problems using the same
>paradigm as before, etc, etc but he didn't seem very convinced. He is a
>professional and he will do what we ask him to do, but I think its important
>to give him the information that he needs to make this change in mind set on
>his own.
>
>
>

I use below argumentation when my friend ask me with the same questions:

Some flat file database stored the table information (number of record,
auto increment generator, fields info etc. etc.) in the file header,
the record position can determine easily (using goto, findkey, etc.)
without much impact of performance. Filtering table can/can't impact
performance depending on some factor such as engine capability to use
index on filter operation.

In result set basis RDBMS like Firebird, there are no information like
that, we have to fetch needed records only to reduce the data transfer
between db engine and client application. We always use SELECT statement
with WHERE clause. Actually TTable component or similar do SELECT * FROM
<ATable> without WHERE clause when using with Firebird.

HTH
HJ