[freetds] Transaction weirdness
John Anderson
ardour at semiosix.com
Fri Oct 10 11:32:24 EDT 2003
On Fri, 2003-10-10 at 05:37, James K. Lowden wrote:
> On 09 Oct 2003, John Anderson <ardour at semiosix.com> wrote:
> > So my code processes the data (1 row) that it needs, and then tries to
> > execute the commit. Since the other (useless) resultset is still
> > pending, the commit attempt fails.
> >
> > Seems to me that from an application point of view it would make sense
> > for a commit attempt to automatically cancel any pending result sets?
>
> Philosophically, regardless of what documentation says? You could take
> that point of view, or you could say that an out-of-place commit indicates
> a logic flaw in the application, because results have to be fetched or
> explicitly cancelled.
Not wanting to be argumentative about this - you guys know a lot more
about it than I do - looking at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odch14pr_8.asp
I find
Committing or rolling back a transaction has the following effect on
cursors and access plans:
* All cursors are closed, and access plans for prepared statements
on that connection are deleted.
* All cursors are closed, and access plans for prepared statements
on that connection remain intact.
* All cursors remain open, and access plans for prepared
statements on that connection remain intact.
Which to me implies that there's no need to explicitly close a cursor
before committing or rolling back a transaction, because the call to
SqlEndTran will do it for me - if that's the option the driver
implements. And the driver will also give me back the relevant value
from SqlGetInfo with SQL_CURSOR_COMMIT_BEHAVIOR.
bye
John
More information about the FreeTDS
mailing list