This topic has always been of interest to me.

Would anybody be able to offer any advice on the table vs query
debate when it comes to grids. Many of my customers like to see
grids summarising information on the main screen of the application.
From this grid, they can drill down into the application. The
obvious component to use here in a local app is a ttable. However on
a c/s app, I can see why a query makes more sense from a resources
point of view. However, how does one treat grids in this instance?
If you have say 2500-3000 records on the database, and you open a
query which is simply 'select * from tablename' are you going to end
up drawing the entire table down over the network?

On a more general note, are there any forums or explanations of what
is best to use and how in terms of c/s programming with particular
regard to Delphi?


If you attach a grid to a query and open it
--- In IBObjects@y..., Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:

> Hi Carlos!
>
> The main reason not to use tables, is that Interbase is a

client/server

> database, and not a desktop database. You have to change the way

you think:

> Your data is no longer residing on your local PC and transporting

them to

> you takes time. Hence, you only transfer what you actually need.

Besides,

> c/s databases may grow much larger than most desktop dbs, and

transferring

> them all simply isn't feasible.
>
> I recommend that you use TIBOTables only for very small tables (<100
> records, albeit I don't think you get any trouble with a bit larger

ones),

> and start getting used to thinking in queries. Users normally aren't
> interested in many records at a time (there is a limit as to how

many they

> can actually read), and calculations can be done on the server.
>
> I think Jason has done a good job in implementing TIBOTable, so

you're

> unlikely to fall into other pitfalls than taking a desktop mindset

into the

> c/s world. Speed and memory resources should be OK if used

correctly. I

> think most of us prefer to use the native components because it

automates

> so much that we don't have to code very much, but if you need to use
> components not compatible with the native branch, use TIBOQuery.
>
> Set