Re: 0.5.3 ORM, MSSQL and FreeTDS: Invalid Cursor State exception?

On Apr 29, 10:08 am, Tom Wood <Thomas.A.W... <at> gmail.com> wrote:
> Some additional info, and a possible fix:
>
> ===================================================================
> --- lib/sqlalchemy/databases/mssql.py   (revision 5930)
> +++ lib/sqlalchemy/databases/mssql.py   (working copy)
>  <at>  <at>  -991,7 +991,7  <at>  <at> 
>              # 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.
>

This change does not affect any of the tests on Windows.  So that's
good.  I'd like to confirm a couple of other things before we commit.
Thanks a lot.

Michael
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalchemy <at> googlegroups.com

Re: 0.5.3 ORM, MSSQL and FreeTDS: Invalid Cursor State exception?

On Apr 30, 11:04 pm, mtrier <mtr... <at> gmail.com> wrote:
> > Some additional info, and a possible fix:
>
> > ===================================================================
> > --- lib/sqlalchemy/databases/mssql.py   (revision 5930)
> > +++ lib/sqlalchemy/databases/mssql.py   (working copy)
> >  <at>  <at>  -991,7 +991,7  <at>  <at> 
> >              # 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 <at> googlegroups.com

Re: 0.5.3 ORM, MSSQL and FreeTDS: Invalid Cursor State exception?

On 27 Apr, 16:01, Tom Wood <Thomas.A.W... <at> gmail.com> wrote:
> Hi all,
>
> Am having a problem withSQLAlchemy0.5.3 and MSSQL.  Running on a
> Debian stack, using FreeTDS 0.82, pyodbc 2.1.4, Python 2.5 and
> (separately) SQL Server 2000 and SQL Server 2005.

I have a fairly comparable setup, with SQLALchemy 0.5.3, Python 2.6,
FreeTDS 0.82, pyodbc 2.1.5, all running on Mac 10.5.  Connecting to
SQL Server 2005 running on a virtual machine.

I've been using the connection string: "mssql://user:password <at> /?
dsn=schematest?driver=FreeTDS"

I can do simple connections using both pyodbc and sqlalchemy.  I can
execute a query, though I don't have any data yet so they only return
empty results.

Trying to create tables tends to cause the following error though:

ProgrammingError: (ProgrammingError) Attempt to use a closed cursor.
None None

Running your test causes the same error, shown below.  I'm a bit stuck
on what to try next, but I'll keep fiddling and let you know of
anything that works for me.

Ed

Re: 0.5.3 ORM, MSSQL and FreeTDS: Invalid Cursor State exception?

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... <at> gmail.com> wrote:
> On Apr 30, 11:04 pm, mtrier <mtr... <at> gmail.com> wrote:
>
>
>
> > > Some additional info, and a possible fix:
>
> > > ===================================================================
> > > --- lib/sqlalchemy/databases/mssql.py   (revision 5930)
> > > +++ lib/sqlalchemy/databases/mssql.py   (working copy)
> > >  <at>  <at>  -991,7 +991,7  <at>  <at> 
> > >              # We may have to skip over a number of result sets with
> > > no data (due to triggers, etc.)
> > >              while True:

Calling flush after delete causes ObjectDeletedError..

Very straightforward, this one.

The following:

    session.delete(p)
    session.flush()

Reliably gets me an ObjectDeletedError exception. p is a known valid object before the delete. No other
update, insert or deletes have taken place.

Here's the last line of the traceback:

  File
"/usr/lib/python2.4/site-packages/SQLAlchemy-0.5.2-py2.4.egg/sqlalchemy/orm/mapper.py",
line 1790, in _load_scalar_attributes
    raise exc.ObjectDeletedError("Instance '%s' has been deleted." % state_str(state))

Known problem or a bug in my understanding ?

Thanks in advance.

--

-- 
t o b e

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalchemy <at> googlegroups.com
To unsubscribe from this group, send email to sqlalchemy+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en

Re: Calling flush after delete causes ObjectDeletedError..

that shouldnt happen, unless "p" is expired and its row has been  
deleted already.  otherwise, you need to send us a test case  
illustrating how youre getting it to do that.

On May 1, 2009, at 12:50 PM, Toby Bradshaw wrote:

>
> Very straightforward, this one.
>
> The following:
>
>    session.delete(p)
>    session.flush()
>
> Reliably gets me an ObjectDeletedError exception. p is a known valid  
> object before the delete. No other update, insert or deletes have  
> taken place.
>
> Here's the last line of the traceback:
>
>  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.5.2-py2.4.egg/ 
> sqlalchemy/orm/mapper.py", line 1790, in _load_scalar_attributes
>    raise exc.ObjectDeletedError("Instance '%s' has been deleted." %  
> state_str(state))
>
> Known problem or a bug in my understanding ?
>
> Thanks in advance.
>

Re: contains_eager and self-referential queries

Re: contains_eager and self-referential queries

On May 1, 2009, at 2:55 PM, David Gardner wrote:

> Along those same lines, one of the things I would like to do is to  
> do an arbitrary join, my table is hierarchical and often I want to  
> do a join against a a node, along with another node two levels deep  
> below it, and since its a tree structure eager loading all of the  
> children, and grandchildren would be costly, when I only care about  
> two of them.
>
> So I have this:
>
> scn_alias=aliased(Asset)
> p='testshow/eps/201/s22/t04'
>
> take = session.query(Asset).filter(Asset.path==p).\
>         outerjoin((scn_alias,scn_alias.path=="%s/anim/ 
> scn"%p),aliased=True).one()
>
> This produces the correct SQL, but since scn_alias isn't directly  
> mapped as a relation to the row I am querying, I can't figure out  
> the correct arguments to pass to contains_eager().

contains_eager just needs to know what columns in the selectable it  
needs to draw from.   so again here, drop the aliased=True since  
scn_alias is already an alias, then pass scn_alias as the "alias"  
keyword to contains_eager().  Also your outerjoin should probably be  
qualified against the parent Asset object otherwise you're in danger  
of cartesian products.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalchemy <at> googlegroups.com
To unsubscribe from this group, send email to sqlalchemy+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: contains_eager and self-referential queries

Re: contains_eager and self-referential queries