> > 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
well)?

Which command actually causes the sql to be executed?

> TIB_Cursor doesn't store the dataset: it fetches the rows one by

one,

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

entire

> 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
meaningless/pointless?

> Of course, you wouldn't usually use the client to do the kind of

procedure

> you are doing here. You would write a stored procedure to perform

this

> cursor operation (your //do stuff) on the server. In your IBO app,

you

> 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 purpose...in 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.

Davd