FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

On Thu, 9 Oct 2003, 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.

> By insisting on explicit handling of the results, the designers prevent
> applications from assuming they've fetched all the rows when they haven't.
>  Lots of programmers make the mistake at one time or another of assuming a
> query will return one row when it actually may return two or more.  This
> way at least, the database won't take the heat for the bad assumption.

There are some stupid things the Microsoft drivers do - one of my
favorites (Not really:) is not failing the connection if an initial 'use
database'  query fails to set your working database.

On the other hand I grew to have a great deal of respect for the
Microsoft ODBC drivers after one of dozens of things failed with other
drivers where the MS version somehow had enough brains to handle my
shortcommings and do what I meant anyway.

What I read of the documentation on SQLTransact is it doesen't say
anything about requiring a certain state (other than connected of course)
before this will work.?

If SQL_CURSOR_COMMIT_BEHAVIOR and SQL_CURSOR_ROLLBACK_BEHAVIOR are set to
SQL_CB_CLOSE (Which is how we currently have them) when SQLTransact is
called then the expected behavior is to axe any currently open cursors on
that handle.

take care,
Peter


> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>