Jason,

>> What does a full refresh exactly mean? Which IBO method should have been
>> called here or is it a matter of closing and re-opening?
>
> This would be like pressing F5 in a grid or calling the Refresh method.
> Under the current implementation, unless the IB_TransForUpdate was
> committed, it would appear as if the changes already made had been lost.

Entirely true.

>> Honestly, I'm not sure, but I guess I wouldn't expect to see
>> non-committed changes by the IB_TransForUpdate in the read transaction.
>> So, if the read transaction is working as read committed, then it simply
>> will see committed changes.
>
> Right, which would be confusing because a query wouldn't be reflecting
> changes that were performed by way of its own Edit, Insert and Delete
> methods.
>
>> I'm not sure either, if I would like to see non-committed changes anyway.
>
> A possible solution is to take advantage of the cached updates
> functionality. When the dataset is refreshed, even though it will get the
> old data from the server, I can make it respect all of the uncommitted
> changes that were previously performed just as I already do when using
> cached updates.
>
> 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 ... ;-)


Regards,
Thomas