Subject | Re: [IBO] 128 K ISDSN Speed and slow update |
---|---|
Author | Geoff Worboys |
Post date | 2001-03-07T00:11:44Z |
> I'm evaluating the IBO.My first point would be to use TIBOQuery rather than TIBOTable, so
>
> I'm running my app. on a computer connected to the IB server
> trough a 128 Kb ISDN line.
> Using IBOTable and TCP/IP connection and IB 6.01
> Default settings on all objects.
> Scroll 3000 items from the first record to the last the first
> time it take about 10 minutes and after the first scroll is
> done it only takes one seconds to do the same thing. I suppose
> that is because the records are cached to the workstations
> memory. Also a insert of a new record will take about 10
> seconds to do. Is there any way to make some settings that
> make it faster.
that you can design your query to only return those fields that are
actually required.
Secondly, whichever you are using, try setting FetchWholeRows = false.
This will cause IBO to only fetch the key fields, and then fetch the
individual row data when actually required.
Try and design your tables so that field sizes are kept to a minimum.
Dont use fields with large VARCHAR definitions, store such values in
blobs which will be loaded separately and only when required.
The long time for the insert is rather interesting, it seems to
suggest to me that there is something wrong with your query OR perhaps
you are storing blobs of significant size OR perhaps your link has
problems. You could try running the SQLMonitor dialog while
performing these tests, the results may help work out where the delays
are coming from.
Writing applications for efficient use across slow links takes a lot
of work and almost always some compromise. For example you may need
to force the users to always search for a very restricted set of
records. You may find it worthwhile using the native TIB_* components
for such work, since these are easier to optimise for this sort of
work. For example lookup controls that can be setup to retrieve a
smaller set of records by only searching after some defined number of
characters have been typed.
If you or your client are not willing to accept the compromises
required to make an application work efficiently across a slow link,
then I suggest you investigate thin client options such as Terminal
Server.
HTH
Geoff Worboys
Telesis Computing