Hi Helen

As an aside to all this, I have a small app running over a VPN (Across
the web) that uses ib_Query. Would changing it to ib_Cursor also reduce
some of the traffic caused when running a Query?

I know I shouldn't run FB over the Interent but in this case the app is
sufficiently small and performance if good.

Rob Martin
Software Engineer

phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com

Wild Software Ltd



Helen Borrie wrote:

> At
> Statement objects get "fatter" as you advance
> through the hierarchy of base classes. The
> thinnest statement object is TIB_DSQL - it
> surfaces the bare TIB_Statement base class. It
> is ideal for all executable statements, including
> those that return a one-line set (such as an
> executable stored procedure, or the return value
> from an INSERT statement in Fb 2.0). TIB_DSQL
> can't be used for SELECT statements.
>
> Next is TIB_Dataset. It is surfaced as
> TIB_Cursor. It is the unidirectional dataset -
> it accepts the set one row at a time but does not
> cache the rows. It is ideal for singleton sets
> or for sets that you want to operate on
> row-by-row (as in my example for loading up
> non-data-aware containers). You can use both
> executable and SELECT statements with TIB_Cursor.
>
> Then you have TIB_BDataset, which is surfaced as
> TIB_Query. the "B" stands for
> "buffered". Underneath, it fetches rows in its
> own loops and provides a lot of other bits and
> pieces of cached stuff. You need it for anything
> that you want the user to scroll through and navigate at random.
>
>