Subject Re: [IBO] TIB_Cursor & AutoFetchAll
Author tickerboo2002
> > curCustomerNames->Execute(); <-- shouldn't be here
> > curCustomerNames->Open(); <---- shouldn't be here

...sigh, even the stuff I thought I knew is wrong :-)

Would 'First' always negate the need for Open (for TIB_Querys as

Which command actually causes the sql to be executed?

> TIB_Cursor doesn't store the dataset: it fetches the rows one by
> "one-off", so the "current row" (the one it is looking at) is the
only one
> in the buffer. If you set AutoFetchAll to true, then once the
> dataset is fetched, the cursor has had every row as "current row"
and is
> now sitting at the end of this buffer - a state which is
encapsulated as
> EOF. Hence, your loop never runs.

In that case, is using AutoFetchAll with a a TIB_Cursor

> Of course, you wouldn't usually use the client to do the kind of
> you are doing here. You would write a stored procedure to perform
> cursor operation (your //do stuff) on the server. In your IBO app,
> would use a TIB_DSQL to accept some parameters and shoot off a SP
> call; and get your job done PDQ with no network overhead.
TIB_Cursor can
> also be used for this both cases, the start-gun is
fired by a
> call to Execute, not First.

In this case I was populating a control, but I understand what you're
saying. My only other database experience has been with SQL Server,
where we had about 95% of the sql contained in SP's because of the
perceived efficiency/speed improvement. With FB/IBO and using complex
sql that returns multiple rows, is the speed improvement of a SP over
sql contained with a TIB_Query quantifiable?

Your help is appreciated.