Jason,
Would it be possible to get a bookmark before the commit and then
return to it after the commit.

--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> Daniel,
>
> For PURE bde emulation you should switch the CommitAction of your
query (at
> run-time using the InternalDataset property) to caFetchAll and see
if that
> makes a difference. For many, this was a horrible problem the BDE
imposed
> upon people because their query would run forever if it had a lot
of records
> in it.
>
> > This is the scenario:
> >
> > IBOQuery.InternalDataset.CommitAction := caFetchAll;
> > IBOQuery.open; // record count = x (say 20 for instance)
> >
> > While not iboQuery.eof do
> > Begin
> > .....
> >
> >
>
> HTH,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "danialwidner" <dwidner@a...>
> To: <IBObjects@y...>
> Sent: Wednesday, June 26, 2002 8:24 AM
> Subject: [IBO] EOF reported after next - missing one record.
>
>
> > I have isolated a problem discovered 2 weeks ago and reported
> > directly to Jason.
> >
> > This is the scenario:
> >
> >
> > IBOQuery.open; // record count = x (say 20 for instance)
> >
> > While not iboQuery.eof do
> > Begin
> > .....
> >
> >
> > DB.StartTransaction;
> >
> > UpdateQuery.execSQL; // update control record as completed
> >
> > DB.Commit;
> > // record count is now x-1 because it requeried.
> > // record 1 is NOT the record we came into the loop with
> > // It is now the original record # 2
> > iboQuery.Next; // we just skipped the ORIGIONAL record # 2
> >
> > End;
> > // record #2 never gets processed.
> >
> > I know that putting the IBOQuery used for control on it's own
> > transaction will fix the problem. However, this is BDE converted
> > code. It could take months to just add that item to all the files
> > and queries that need it. Standard BDE operation needs to be
> > restored / implemented (IE don't refire IBOqueries on commit if
the
> > values in the query itself have not been altered. Whatever).
> >
> > Perhaps have independent internal transactions for each query.
Then
> > from the DB StartTransaction action track a "Dirty" flag for
those
> > tranactions that are exececuted in some / any way before the
> > commit / rollback action. Then only commit / rollback the dirty
> > transactions leaving the clean external loop transactions alone.
> >
> >
> > Dan