At 06:24 AM 1/10/2002 +0000, you wrote:

>Hi
>
>We're doing a paradox to ibotable conversion D5 - IB4. IN our app we
>had a few datamods with many active ttables on app creation. This
>worked fine with paradox but converted to ibotables a sudden
>reduction in speed of startup.
>
>Cleary our model has to change - but I just want to know what each
>active tibotable is doing as the app is created. What data does it
>send to the client ( since an active tibotable is essentially
>a 'select * from' ). When I watch the SQL monitor I do not see tons
>of row data - So is there maybe data buffers prepared on the server
>side ?
>
>I also noticed it is the tables with the most no of fields ( not the
>most data ) that take longer to load up.
>
>Thanks - Rod

Rod,

When you open a TDataset all of the field information is fetched from the
server and a list fo field objects are created in the client object. That
is most likely what you are seeing.

As a general rule with SQL databases you should drop all use of TTable type
objects and use Query objects instead.

Then create and open the query as needed.

When using data modules, it is also beneficial to create multiple data
modules with less objects in each one. For every instance all the objects
on the form need to be created. If you load a huge data module just to get
a small piece of data for a form then you have a lot of overhead thatis not
needed.

I usually build a data module with a list object (TIBOQuery) and an edit
object (TIBOQuery with a single record select). Then the DM has
manipulation methods for manipulating the dataset objects. My forms never
do any data manipulation. Only the DM can do that. The forms just make
requests of the data module.

Best Regards,

Allen.