Thomas,

> > In short, I would add in a new cached updates status of cuPosted and
> > keep track of them for refresh purposes.
>
> Had a look on how IBDAC is handling this situation. According to the
> generated Firebird 2.5 trace output, when clicking the refresh button of
> a TDBNavigator while there is a pending change issued by editing
> something in a TDBGrid, IBDAC is doing a commit (retaining). This
> obviously fails of course, while you are in editing a record and the
> record doesn't fulfill every server-side constraints (FK, unique, ...)
>
> So, if you intend to solve the refresh problem without doing a commit
> and being in the same edit state afterwards ... ;-)

Right, they are not able to deal with a refresh without forcing a commit of
all changes.

My method would be to force the current record posted if they are in an edit
state and then without forcing a commit I would allow the dataset to
refresh, which would bring the old versions of the record from the server.
However, I would store all of the cached changes they have not yet committed
and apply them against the records coming in as the refresh takes place.
That way the edits will still show up, and so on.

Make sense?

Jason