|Subject||Re: [IBO] TIB_Cursor & AutoFetchAll|
> > curCustomerNames->Execute(); <-- shouldn't be here...sigh, even the stuff I thought I knew is wrong :-)
> > curCustomerNames->Open(); <---- shouldn't be here
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 byone,
> "one-off", so the "current row" (the one it is looking at) is theonly one
> in the buffer. If you set AutoFetchAll to true, then once theentire
> 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 isencapsulated 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 ofprocedure
> you are doing here. You would write a stored procedure to performthis
> 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 SPTIB_Cursor can
> call; and get your job done PDQ with no network overhead.
> also be used for this purpose...in both cases, the start-gun isfired 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.