At 07:18 AM 7/09/2006, you wrote:

>Carlos García Trujillo wrote:
> > Thanx Dany...
> >
> > I was digging in the source code of IBO, and found that Jason use
> > TIB_SchemaCursor in those queries...
> >
> > should i use TIB_SchemaCursor for my query instead of TIB_Cursor???
> > what are the differences???
>
>I can see he used a TIB_Dataset (parent of TIB_Cursor). This will have
>less functionality than TIB_Cursor and would (theoretically) perfor
>somewhat faster on the client side.

Not true. TIB_Dataset is surfaced as
TIB_Cursor. You don't create instances of the base class.

I must have misunderstood. I thought you wanted a *lot* of rows. In the

>schemachache fetching there is a loop (while not eof).

Because it needs a loop for its specific functionality.

You can read a TIB_Cursor in a loop if you wish
to. For example, I typically have functions in
my apps that open a TIB_Cursor to read (at create
time) and refresh (in response to certain events)
non-data-aware controls (or the non-data-aware
parts of data-aware controls) such as stringlists, listboxes, and so on.

>And apparently I thought of the chapter "Walking through records in a
>Dataset" in the Tech info sheet "Working with IBO Datasets". I thought
>AfterFetchRow was used in the schemacache code. Since it's not, the
>schemacache way should be faster because it does not do callbacks.

Datasets don't do callbacks unless you tell them to.

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.

>However, I guess that in order to save time working on the client side
>like this you'll need a very fast connection and a rather slow client
>machine.

I'm not sure of the meaning here, but maybe I
have missed something in the problem
description. For a 2-tier client/server
application you need a network with reasonable
speed. If you have clients connecting from the
Internet, even ADSL is too slow to be considered
"reasonable" for interactive work 2-tier.

Helen