Mike ... thanks for picking this up! Just so you know, I haven't done any other testing of my change to see how it interacts with, say, db triggers that fire on the insert.
I can add an another small bit of info: I also see the dialect unit test failures (test_fetchid_trigger and test_slice_mssql) against SQLAlchemy 0.5.3, otherwise same configuration as above. Just curious: were you able to reproduce the "invalid cursor state" exception using FreeTDS? I'm frankly nervous that there is something funny about our stack, although another developer here has been able to reproduce the problem on a separate system (Debian again.) -Tom On Apr 30, 11:06 pm, mtrier <mtr...@gmail.com> wrote: > On Apr 30, 11:04 pm, mtrier <mtr...@gmail.com> wrote: > > > > > > Some additional info, and a possible fix: > > > > =================================================================== > > > --- lib/sqlalchemy/databases/mssql.py (revision 5930) > > > +++ lib/sqlalchemy/databases/mssql.py (working copy) > > > @@ -991,7 +991,7 @@ > > > # We may have to skip over a number of result sets with > > > no data (due to triggers, etc.) > > > while True: > > > try: > > > - row = self.cursor.fetchone() > > > + row = self.cursor.fetchall()[0] > > > break > > > except pyodbc.Error, e: > > > self.cursor.nextset() > > > > I.e., calling fetchall() instead of fetchone() seems to clean up the > > > cursor state. > > Also, FWIW, the original test passes just fine on Windows and pyodbc. > So it's definitely a FreeTDS issue. > > > > > Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
