At 08:37 AM 08-08-02 +0000, you wrote:

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

No. Use First for an IB_Cursor dataset, Execute for an IB_Cursor DML or an
executable IB_StoredProc or an IB_DSQL operation; and Open for an IB_Query
or a selectable IB_StoredProc.

>Which command actually causes the sql to be executed?

Whichever one of the above you call. But you get an error if you call the
wrong one.

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

Usually.

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

Yes: but you have to use the right tool for the job. Fetching rows for
interactive editing via a selectable SP that does nothing except mimic a
DSQL query is just as silly as pulling a dataset across the wire in order
to do non-interactive DML.

SQLServer doesn't have the equivalent of a selectable SP; and the
concurrency problems in its dynamic SQL are so dreadful that many just
throw in their hands, write cursor procs for every dataset, do all their
interactive stuff on temporary tables and take their chances on posting
updates. With FB/IB and its very clever versioning engine, you are spared
all of those horrors, thanks be.

regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com