On Apr 29, 2009, at 10:08 AM, Tom Wood <thomas.a.w...@gmail.com> wrote:
>
> Some additional info, and a possible fix:
>
> I can reproduce this problem running the SQLAlchemy dialect unit
> tests. Using a trunk (r5930) checkout, FreeTDS 0.82 with tds protocol
> version 8.0, pyodbc 2.1.4, Python 2.5 and SQL Server 2005, I see three
> test failures in dialect.mssql:
>
> test_binary fails with:
>
> DataError: (DataError) ('22018', '[22018] [FreeTDS][SQL Server]
> Implicit conversion from data type varchar to varbinary is not
> allowed. Use the CONVERT function to run this query. (257)
> (SQLPrepare)') 'INSERT INTO binary_table (primary_id, data,
> data_image, data_slice, misc, pickled, mypickle) VALUES
> (?, ?, ?, ?, ?, ?, ?)' [1, <read-only buffer for 0x842e680, size -1,
> offset 0 at 0xb75c8f80>, <read-only buffer for 0x842e680, size -1,
> offset 0 at 0xb75c8f60>, <read-only buffer for 0xb75e9c20, size -1,
> offset 0 at 0xb75d00a0>, 'binary_data_one.dat', <read-only buffer for
> 0xb75c67a0, size -1, offset 0 at 0xb75d0180>, <read-only buffer for
> 0xb75d9d68, size -1, offset 0 at 0xb75d0100>]
>
> I'm going to ignore this for now, since it seems to be unrelated to my
> problem.
This failure has started about a month ago and I haven't had time to
investigate.
>
>
> However, test_fetchid_trigger and test_slice_mssql both fail with the
> Invalid cursor state exception:
>
> File "/home/taw00008/src/sqlalchemy-trunk/lib/sqlalchemy/engine/
> base.py", line 931, in _handle_dbapi_exception
> raise exc.DBAPIError.instance(statement, parameters, e,
> connection_invalidated=is_disconnect)
> ProgrammingError: (ProgrammingError) ('24000', '[24000] [FreeTDS][SQL
> Server]Invalid cursor state (0) (SQLExecDirectW)') 'INSERT INTO foo
> (bar, range) VALUES (?, ?); select scope_identity()' [1, 1]
>
> Here's a possible fix. The following patch to mssql.py corrects my
> problems, as well as the test_fetchid_trigger and test_slice_mssql
> failures:
Interesting fix. I'll apply and test against windows and pyodbc.
>
>
> Index: lib/sqlalchemy/databases/mssql.py
> ===================================================================
> --- 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.
>
> Two caveats: (1) there are many other (non dialect) test failures with
> and without my patch, although the patch does reduce the number. So
> maybe there is something amok with my configuration. (2) I'm only
> tried this on Debian--I have no idea what would happen on Windows.
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
