On 2002.12.13 10:51:38 -0500 Ann W. Harrison wrote:

> At 10:30 AM 12/13/2002 -0500, David Jencks wrote:
>
>
>
> >Hmmm, Well, the purpose of the changes to rollback were so you could
> call
> >rollback on the engine if there is any evidence a transaction was
> started,
> >and to mark the transaction over no matter what happens. This is only
> >required when you are making a last-ditch attempt to clean up after some
> >kind of serious problem and are about to discard the connection.
>
> Actually rollback is often used without breaking the connection, in
> the case of data conflicts in transaction processing systems. The
> "reason" for rollback retaining is to allow Delphi clients to undo
> work after a data conflict without losing all their context - in
> Delphi, when there is no active cursor, there is no data.

[Old delphi -- I always used client datasets. But then I had to work
against Oracle]

>

Right, and then you don't expect an exception from calling rollback. The
changes I made were so rollback could always be called even after a fatal
(e.g. Object In Use error) commit exception, and the tx would be gone after
you called it. "Normal" operation without "I give up" exceptions should be
unchanged. Basically we had a little too much state checking about when
you could call rollback, and too little exception handling after.

david jencks

>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>