FreeTDS Development Group

["Michael Horowitz" <michael.horowitz AT storagenetworks.com>]

Hello,

I don't know if this is the same issue, but I remember reading about
issues with disconnects and commit/rollbacks with the Perl DBI module.  It
said, "The transaction effect of explicitly disconnecting from a database
while AutoCommit is disabled is, sadly, undefined.  Some database systems,
such as Oracle and Ingres, will automatically commit any outstanding
changes.  However, other database systems, such as Informix, will roll
back any outstanding changes.  Because of this, applications not using
AutoCommit should always explicitly call commit() or rollback() before
calling disconnect()."  If you are familiar with DBI, it goes on to
explain in the event that the program exits without explicitly calling
disconnect(like after a die), that the DESTROY method is called, and that
the implementation of the DESTROY method is in the hands of the driver
author.  They say that it SHOULD call rollback before calling disconnect
if AutoCommit is disabled, and that all drivers that they are aware of do.

I am not sure if this helps, but the principle is probably the same with
any libraries.  I am not sure what the default behaviour is for SQL
Server, but I think I remember that it was the opposite of Oracle, which
means that on explicity disconnects a transaction is rolled back.  For ALL
databases, I would at least hope that if the connection is lost and not
explicitly properly closed by the client, then the transaction should
always be rolled back.

--Mike

> HI,
> 
> 
>    If I close the statement before calling
> Connection.commit(), the transaction is not committing
> to database.
> 
>  May I know what is the problem/workaround to this ?
> 
> Kalyan.
> 
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com