If you are using TTable then it had better be setup to do the navigational
scrolling rather than the monolithic approach. This means that you walk the
fine line so that the BDE won't fetch all the rows of the dataset. It's
pretty tough to keep it under control so most people just curse TTable and
swear to never use it again.

With IBO 4 you will have the nice navigational scrolling capabilities with
100% flexibility. There won't be blind spots like there were with TTable.

By far the best way to do a client server application is using the native
IBO components and controls and use search mode where the user types in
simple search criteria and fetches just the records of interest instead of
having to sift through hordes of data with their eyes to find what they
want.

Friendly to the network and friendly with the users eyes.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: <stewartbourke@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, May 09, 2001 1:41 PM
Subject: Re: [IBO] Tables versus Querys


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




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/