FetchAll fails to return rows when running against a connection instantiated with as_dict=True.

[GoogleCodeExporter]

Reproduction Steps:
1. Open a connection with as_dict = True.
2. Open a cursor and run a select query.
3. Attempt to return rows using cursor.fetchall().

The fetchone() routine works without a hitch, so there doesn't seem to be an 
issue in collecting the data, just in how it's being returned from the 
fetchall() command. Both fetchone and fetchall work fine on non-dict 
connections.

I'm using Python 2.6.5, with xi's new build of pymssql (with the FreeTDS 
nightly), so I'm not sure if this is an issue related to that specific build, 
or the new version of pymssql. (I can't test the "official" build, since 
importing pymssql crashes python.) 

I'm running against SQL Server 2005 on Windows Server 2008.

Original issue reported on code.google.com by eavesdown on 24 Aug 2010 at 9:57

[GoogleCodeExporter]

Confirmed here. Also happens with fetchmany. 

File "pymssql.pyx", line 351, in pymssql.Cursor.fetchmany (pymssql.c:4349)
    self.batchsize = size
AttributeError: 'pymssql.Cursor' object has no attribute 'batchsize'

Original comment by rizw...@gmail.com on 1 Nov 2010 at 4:13

[GoogleCodeExporter]

Ditto. fetchall() does not work with as_dict = True. This is very frustrating 
as I will have to rework code to fetch as non-dictionary (I was testing with 
MySQL).

I also get the error with 'batchsize'.

Is there a fix for this coming soon? It appears this bug has been around for 
some time.

Original comment by Augmente...@gmail.com on 11 Nov 2010 at 11:23

[GoogleCodeExporter]

I suppose one other option is to convert the fetched rows to dictionary options 
using a routine of my own.  Just an idea.

Original comment by Augmente...@gmail.com on 11 Nov 2010 at 11:26

[GoogleCodeExporter]

Agreed. 

I can't figure out if the bug is in the c layer; so I haven't worked on a patch.

Original comment by htt.supp...@gmail.com on 12 Nov 2010 at 12:04

[GoogleCodeExporter]

I am fairly sure this is fixed in the latest subversion revision from looking 
at the code. I am going to try to push out 1.9.909 in the next couple of days.

Original comment by dam...@gmail.com on 5 Jan 2011 at 12:05

[GoogleCodeExporter]

Original comment by dam...@gmail.com on 8 Mar 2011 at 3:37

• Added labels: PyMssql-2.x

[GoogleCodeExporter]

Is there still a chance of seeing a release of 1.9.909 in the near future? I'm 
always tentative about using non-full releases, in case any functionality is 
temporarily bugged or disabled.

Original comment by eavesdown on 8 Jun 2011 at 8:57

[GoogleCodeExporter]

Sorry for not being able to tell you that, I don't currently have a release 
schedule mapped out and not sure the other devs do either.

That being said, your best bet right now is to pull from the HG repo.  That 
code is currently pretty stable.  It passes all our internal tests as well as 
most of SQLAlchemy's tests when used as driver.

Original comment by rsyr...@gmail.com on 8 Jun 2011 at 10:51

[GoogleCodeExporter]

Any updates on a release for 1.9.909?

Original comment by rizw...@gmail.com on 4 Oct 2011 at 3:39

[GoogleCodeExporter]

Original comment by rsyr...@gmail.com on 8 Mar 2012 at 3:26

• Changed state: Accepted

[GoogleCodeExporter]

I don't know about a 1.9 release (I think that no new work is planned on 
pymssql 1.x?), but I couldn't reproduce this in the hg tip:

marca@marca-mac:~/dev/hg-repos/pymssql$ cat issue_18.py import pymssql

conn = pymssql.connect( server='SERVER', user='pymssql_dev', password='PASSWORD', database='pymssql_dev', as_dict=True)

cursor = conn.cursor() cursor.execute('SELECT * FROM people')

data = cursor.fetchall() print('data = %r' % data) marca@marca-mac:~/dev/hg-repos/pymssql$ .tox/py27/bin/python issue_18.py data = [{0: 'Marc', 1: 'Abramowitz', 'first_name': 'Marc', 'last_name': 'Abramowitz'}, {0: 'Zach', 1: 'Abramowitz', 'first_name': 'Zach', 'last_name': 'Abramowitz'}]

Both column names and numbers are present, which might be a bug, but that has 
been reported elsewhere as http://code.google.com/p/pymssql/issues/detail?id=92

Randy, do you think that we can close this issue?

Original comment by msabr...@gmail.com on 9 Jan 2013 at 7:17

[GoogleCodeExporter]

Just make sure we have a test that covers the above functionality.  Assuming it 
works, as you describe, then yes I'd say it can be closed.

Original comment by rsyr...@gmail.com on 9 Jan 2013 at 7:25

[GoogleCodeExporter]

Added a test to show that the issue isn't occurring anymore:

http://code.google.com/p/pymssql/source/detail?r=058d761cc7614053b28ee2041efe487
3da834111

Original comment by msabr...@gmail.com on 10 Jan 2013 at 12:56

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by msabr...@gmail.com on 10 Jan 2013 at 1:10

[GoogleCodeExporter]

Is there any chance you could generate a new Win32 build for me to test this 
with? I've tried compiling it with MinGW, but I get compile errors because I 
don't have the sybdb library (and the FreeTDS libsybdb included in the *nix 
folders doesn't seem to work).

Original comment by eavesdown on 10 Jan 2013 at 2:24

[GoogleCodeExporter]

Hi eavesdown,

Speaking for myself, I have zero experience with building on Windows so even if 
I managed to pull it off, it would probably take a while. Maybe another dev 
such as Randy could help?

I did take a quick look and I noticed that there seems to be Windows libraries 
in pymssql\freetds\vs2008_32\lib --- db-lib.lib and tds.lib -- it seems that 
the Windows build should be pulling those in. I'm not knowledgable about the 
Windows build, but if it's insisting on libsybdb, that might be a bug in how 
the pymssql setup.py handles Windows or MinGW. Do you have Visual Studio to try 
it with?

Original comment by msabr...@gmail.com on 10 Jan 2013 at 7:41

[GoogleCodeExporter]

I have an another version of VS installed (not 2008) which I attempted the 
build in, and it failed there. I might be able to find and install a copy of 
Visual Studio 2008, but, given that it may conflict with my currently installed 
version, I'm a little wary of installing it just to try to compile this one 
project. I normally compile everything C-based with MinGW, and it's always 
served me fine in the past. I suppose I'll just wait until there's another 
"official" release, with Windows builds included.

Original comment by eavesdown on 10 Jan 2013 at 8:15

[GoogleCodeExporter]

Hi eavesdown,

This isn't official as I am not a Windows guy and I'm very new to pymssql, but 
I did manage to get a build of pymssql going with Visual Studio 2008. Here's 
the installer:

http://pymssql.googlecode.com/files/pymssql-2.0.0b1-dev-20130111.win32-py2.7.exe

Are you up for trying that out and seeing whether it fixes the issue that you 
reported?

Original comment by msabr...@gmail.com on 11 Jan 2013 at 5:59

[GoogleCodeExporter]

We're still using Python 2.6 for our development work, so I couldn't install 
your build for testing. However, since you mentioned the build went smoothly 
with Visual Studio, I went ahead and chanced installing it beside our current 
version of Visual Studio. Sure enough, PyMSSQL compiled without a hitch using 
VS2008. I tested the new build, and the bug indeed appears to be completely 
fixed.

Thanks for your work on this issue. I can't wait to get away from those 
dastardly old NT SQL libraries.

Original comment by eavesdown on 11 Jan 2013 at 7:04

[GoogleCodeExporter]

Marking as verified since eavesdown (original reporter) verified that it's 
fixed. Thanks!

Original comment by msabr...@gmail.com on 11 Jan 2013 at 7:24

• Changed state: Verified