TIBOTable components can take a bit longer to prepare because of the extra
cursors used internally in order to emulate the nice operational
performance. The cost is one-time only. If you have TTable's that were just
for smaller record sets then it will help to set the AutoFetchAll to true.
This will make it orient towards preparing in a simpler way because it will
know to anticipate buffering the whole table instead of using a virtualized
view of records in the table.

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

----- Original Message -----
From: "rodbracher" <rod@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, January 09, 2002 11:24 PM
Subject: [IBO] Whats really happening with tibotables ?


> 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
>
>