Hello Jason,

>>> 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?

Absolutely.


Cheers,
Thomas