Hi Paul, Could this be one of those situations where MSSQL returns multiple result sets? If the select for @@identity / @scope_identity() generates another result set, MSSQL want a full fetch on the previous fetch before issuing a new one. Fix would be client-side cursors for adodbapi, pyodbc would need to implement nextset().
But it's hard for me to believe the problem is as simple as a select @@identity inside a transaction - surely some one (or one of the tests) would have hit that one before. Rick On 3/12/07, Paul Johnston <[EMAIL PROTECTED]> wrote: > > > Hi, > > I've had a go at implementing scope_identity, with mixed results. > > It works fine with pymssql > With adodbapi, scope_identity() always returns None > Same problem with pyodbc, and I uncovered a worse problem lurking (it > exists with @@identity) > If you do an insert inside a transaction (i.e. autocommit doesn't > happen), when it tries to extract the ID, you get the dreaded "Invalid > cursor state" error. > > So, for the time being I think we should hold fire on scope_identity. I > will see if I can figure out what's up with adodbapi/pyodbc. > > Paul > > > > Tim Golden wrote: > > >I've looked through the mailing list and can't see > >this issue raised there so... > > > >There is a known issue with retrieving the id of the > >last inserted row under MSSQL where IDENTITY cols are > >used and there are triggers involved. It's pretty easy > >to demonstrate. If I have this construction: > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
