--- In IBObjects@yahoogroups.com, "Support List" <supportlist@...> wrote:

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

This might be a bit confused. If I have a heavily centralised design model meaning that all BI is implemented in triggers (and SPs - but this is beside the point here) then even a post will not do when pressing F5. Currently with ONE transaction the F5 will "return the answer" to the user/app and the same might decide to commit or rollback later.Actually new users often exclaim "is it possible to update withour saving? cool!".

My confused 5c,

/Dany