Subject Re: cannot disconnect database with open transactions
Author theghost_k8
How much true is this??

The biggest problem with this pertains to open transactions - the
database still thinks the transactions are active and the program
thinks they aren't. As a result, there is no way to simply stop them.
Actually, they need to be rolled back and there is no mechanism to do
that.
i read that from :
http://mc-computing.com/Databases/Delphi/IBX_Connection.html


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 06:30 PM 11/02/2007, you wrote:
>
> >hi there,
> >the problem here is i am not using the transaction in any ways !!
>
> Oh yes you are! Firebird is a transactional database. If you have
> an active connection then you have at least one transaction.
>
> >its just a common connection and command object !!
>
> This sounds like Visual basic and driver-speak - are you using the
ODBC driver?
>
> >using same conn i fire 2 select queries and a stored proc. nothing
else.
> >i don't know how this active transaction occurs in this scenario.
>
> On a "dumbed-down" interface like ODBC, the driver layer is creating
> the transaction (usually a single transaction) for you
> automatically. The Firebird driver will provide you with some
> specific mechanisms for testing whether your client application has
> uncommitted transactions. You will need to ask on the
> firebird-odbc-devel list about this.
>
> >can i get, by any way the transaction-handles so that i can handle
> >them?
>
> You probably have only one and the driver will have a property by
> which you can access it. Again, this is a driver-specific issue.
>
> >is there any way i can get count of active-transactions?
>
> If your driver layer supports multiple transactions then it will (or
> should) give you a way to enumerate them and operate on them as a group.
>
> You don't have any way to know about transactions owned by other
> connections/applications/application instances, etc., and you don't
> need to know. Your connection instance doesn't have access to
> another connection's transactions, by design. Your connection is
> concerned only with the transactions that pertain to itself.
>
> ./heLen
>