Subject | Re: [IBO] Open vs. First |
---|---|
Author | Helen Borrie |
Post date | 2004-11-15T06:28:21Z |
At 09:58 PM 14/11/2004 -0600, you wrote:
of an unbuffered query.
call First. Calling First, Next, etc. opens the row buffer anyway.
you are testing for EOF, you won't get an AV from this code. First should
be called first to start the fetch since the set might not return any
rows. If you call First and you are at EOF, then you know that there are
no eligible rows.
for selection purposes. If the set is highly static, I won't have any
reason to want to run this query again during a session, so I'll unprepare
it. But, normally, if you are going to allow refreshes, it saves a lot of
resource overhead to keep the datasets prepared.
Helen
>ICertainly. You Open buffered datasets, you call First to get the first row
> >Never use counts!! Use the IsEmpty property for queries; for ib_cursors,
> >call First and then check EOF.
> >
>
>Helen:
>
>Is there any reason why "First" instead of just "Open"?
of an unbuffered query.
>For example, would you advise against this kind of code (for anyShould be First. All Open does is open the row buffer and wait for you to
>reason?) (curSomeData is a TIB_Cursor component in a Delphi app, with
>the SQL property assigned at design time.)
>
>procedure SomeProcedure(iParam:integer);
>begin
> with curSomeData do try
> if not prepared then prepare;
> Params[0].AsInteger := iParam;
> Open;
call First. Calling First, Next, etc. opens the row buffer anyway.
> if not eof then while not eof do beginIt so happens that Next will get you the first record in the cursor. Since
> Next;
you are testing for EOF, you won't get an AV from this code. First should
be called first to start the fetch since the set might not return any
rows. If you call First and you are at EOF, then you know that there are
no eligible rows.
> end;Sometimes, yes. Myself I use ib_cursors mostly for populating stringlists
> finally
> close;
> end;
>end;
>
>Is there any need/reason to unprepare?
for selection purposes. If the set is highly static, I won't have any
reason to want to run this query again during a session, so I'll unprepare
it. But, normally, if you are going to allow refreshes, it saves a lot of
resource overhead to keep the datasets prepared.
Helen