cursor.fetchall causes memory leak when a * is used in MySQL string.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. cursor.execute("SELECT * FROM table WHERE 1")
2. rows = cursor.fetchall()

What is the expected output? What do you see instead?
  Would expect for rows to be populated, instead python hangs and the memory builds until swaps.

What version of the product are you using? On what operating system?
  Pyodbc 2.1.11, MySQL ODBC 3.51 Driver, CentOS release 6.1 (Final).

Please provide any additional information below.
  Works ok on RHEL5 with same setup so may be a missing / incompatible lib with CentOS.  Running SELECT with all of the table headers (rather that *) works ok.

Original issue reported on code.google.com by cyborg10...@gmail.com on 23 May 2012 at 1:56

[GoogleCodeExporter]

Weird, because pyodbc simply passes the string on. It shouldn't be different 
unless the MySQL driver is doing something unusual.  Are you sure the drivers 
are the same on the two boxes?

Also, can you test this with pyodbc 3.0.x?  It works on both Python 2 and 
Python 3.  There were some large changes and the issue might already be fixed.

Original comment by mkleehammer on 23 May 2012 at 8:08

• Changed state: Hold

[GoogleCodeExporter]

I'm pretty sure the same as I've reinstalled them.  With the latest, I get this

Error: ('07006', '[07006] [MySQL][ODBC 3.51 Driver][mysqld-5.0.77]Restricted 
data type attribute violation (508) (SQLGetData)')

With the same comand (a simple SELECT that should return 50 odd rows).

Original comment by cyborg10...@gmail.com on 24 May 2012 at 8:28

[GoogleCodeExporter]

MySQL has as bug when using the 3.51 driver and using a Decimal column type.  
Is the RHEL5 table using decimal types?

MySQL Bug: http://bugs.mysql.com/bug.php?id=3028

They have fixed this bug in the 5.1 driver.  The original quick fix during this 
bug fix was to change the column type from a Decimal to a Double but this is 
NOT a good fix, however, it may be a decent test if you are able to run this.

Original comment by dkleeham...@gmail.com on 12 Jun 2012 at 8:27

[GoogleCodeExporter]

Thanks.  They're both looking at the same table, but I think RHEL5 install has 
an older odbc build.  I will try 5.1 and let you know.

Original comment by cyborg10...@gmail.com on 18 Jun 2012 at 8:54

[GoogleCodeExporter]

The only think I can add for now is the same DSN with the same command works 
when using isql which is odd.

Original comment by cyborg10...@gmail.com on 18 Jun 2012 at 9:00

[GoogleCodeExporter]

And can confirm that the issue is still there with 5.1.11.

Original comment by cyborg10...@gmail.com on 18 Jun 2012 at 11:14

[GoogleCodeExporter]

Good morning.

After reading through the aforementioned bug report, I found that the bug still 
resided in MyODBC versions < 5.1.2.

If you look at the bug report for:
[17 Oct 2007 6:45] Georg Richter

you will see that he was still having the same issue as you.  Below his post, 
is another:
[3 Jan 2008 5:02] Jess Balint
Fix committed into svn r983, will be released in Connector/ODBC 5.1.2.

Can you test this with 5.1.2?

Last question, is one of your boxes a 32bit and the other a 64bit?  I'm 
wondering if MyODBC is having an issue with decimals under one or the other.

Original comment by dkleeham...@gmail.com on 19 Jun 2012 at 2:14

[GoogleCodeExporter]

Will retry with 5.1.2, but still doesn't explain why it's working with isql but 
not pyodbc?  Both are 64-bit, but one is Intel, the other AMD (RHEL).

Original comment by cyborg10...@gmail.com on 19 Jun 2012 at 2:24

[GoogleCodeExporter]

If you are still having issues, can you post up a sql trace and I'll take a 
look at it?

I have seen queries work on unixodbc that haven't worked on isql, but not the 
other way around.  Since there is a difference, it could be possible that this 
is one of those times.

As mentioned by Michael Kleehammer, pyodbc is an abstract interface and only 
passes queries and data to the driver and to the app.  Things that have 
mattered with pyodbc on Linux are usually python & pyodbc architectures, odbc 
architecture, driver architecture, as well as, unicode or ascii settings.

Original comment by dkleeham...@gmail.com on 19 Jun 2012 at 9:13

[GoogleCodeExporter]

pyodbc does call a bunch of functions to examine the datatypes of returned 
data.  It is possible that isql doesn't care and simply asks for everything to 
be put into strings.

Can you generate an ODBC trace of each?  If we see how they differ, I might be 
able to work around the problem.

Original comment by mkleehammer on 24 Jun 2012 at 11:30

[GoogleCodeExporter]

@mkleehammer  How do I perform an ODBC trace?  Never done one before!

Thanks

Original comment by cyborg10...@gmail.com on 25 Jun 2012 at 9:10

[GoogleCodeExporter]

If you are using a DSN from your odbc.ini file, you would add the following two 
lines under your DSN entry:

[<yourdsn>]
Trace       = On
TraceFile   = /tmp/sql.log

(The value for Trace may be Yes...)

I should create a wiki page for this.

Original comment by mkleehammer on 26 Jun 2012 at 1:31

[GoogleCodeExporter]

[MySQL]
Description = MySQL
Driver = MySQL ODBC 5.1 Driver
Server = webserver
Database = web
Port = 3306
User = tool
Password = ****
Trace = yes
TraceFile = /home//joe/sql.log

I've also tried "on", but not getting a log (even if I run a command that 
works).

Original comment by cyborg10...@gmail.com on 26 Jun 2012 at 2:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Good morning,

From MySQL's documentation, it says the settings the driver will recognize are:
TraceFile  = /tmp/odbc.trace
Trace      = 1

Also, check your TraceFile settings, the one you posted has two forward 
slashes, which shouldn't matter, but some drivers are picky.  Your code will 
also need write privileges to your directory.

Original comment by dkleeham...@gmail.com on 26 Jun 2012 at 2:59

[GoogleCodeExporter]

Still not getting any output.  I've set Trace=1 and removed the double slash.

This DSN is set in my home .odbc.ini, does this trace need to be done from the 
/etc/odbc.ini?

Original comment by cyborg10...@gmail.com on 26 Jun 2012 at 3:10

[GoogleCodeExporter]

You will need to set this in whichever odbc.ini file you are using the DSN 
from.  If the DSN you are using is located in the /etc/odbc.ini, then yes.  You 
may need to comment out your home directory DSN or the /etc/odbc.ini to confirm 
which DSN you are using and then update that one with the trace file settings.

Original comment by dkleeham...@gmail.com on 26 Jun 2012 at 3:23

[GoogleCodeExporter]

The DSN is specified in my home (the one I've copied here), which is where I've 
put the Trace=1/yes/on and TraceFile.

I'm going to try this on another box to see if there's any difference.

Original comment by cyborg10...@gmail.com on 26 Jun 2012 at 3:26

[GoogleCodeExporter]

I can confirm that 3.0.6 has fixed this issue

Original comment by cyborg10...@gmail.com on 28 Aug 2012 at 8:34

[GoogleCodeExporter]

Original comment by mkleehammer on 29 Sep 2012 at 4:49

• Changed state: Complete