At 11:36 AM 21/03/2005 +0000, you wrote:

> > Because you haven't inserted a record in the dataset, but in a
> > cache buffer that is isolated from the dataset's transaction!
>
>Oops!
>
> > Your problem here is that your code separates the cache from the
> > transaction in which the task occurs. The sequence has to be
> >
> > Transaction.StartTransaction
> > Query.Open (or Refresh)
> > ...
> > Query.Insert
> > (insert rows into the cache)
> > ... (mess around inside the cache if desired)
> > Query.ApplyUpdates (posts all new rows)
> > ...
> > Transaction.Commit
> > Query.CommitUpdates
>
>I just tried exactly that and still nothing gets to the DB. After the
>Insert, UpdatesPending still returns FALSE.

Can you explain when and how you are testing UpdatesPending?

>Is there other possible cause?

Until you scroll off the row in question, the "changes" don't exist
anywhere but in the control. Remember, "update" is at row-level - the
cache buffer will be updated once the datasource knows that the row is
complete. At that point, it will loop through all of the columns and flag
all new values as Modified. At the end of this loop, UpdatesPending will
be set true if it is not already true.

Now, if you are seeing truly anomalous behaviour, check the Requestlive and
Keylinks properties of the dataset; or consider the composition of the
output set: perhaps it is not an updatable set?

Helen