greenew / pypyodbc

Automatically exported from code.google.com/p/pypyodbc
0 stars 0 forks source link

Column names get wonky on 64-bit system using iSeries DB2 driver #45

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Find someone with the iSeries DB2
2. Get hold of the iSeries DB2 driver from your IBM entitled support person
3. Install the drivers on Ubuntu 12.04 LTS
4. Configure unixodbc to access your system
5. Run the following query:

SELECT * FROM qsys2.systables FETCH FIRST ROW ONLY

6. Use the following python code:

# Do import & connection
for row in cursor.execute(sql):
    print(row.cursor_description)

7. The column name (the [0] value of cursor_description) will be b'x' where x 
is whatever the first letter of the column name is

What is the expected output? What do you see instead?

Instead of "my_column" you'll see b'm'

Please provide any additional information below.

If you look at Cname.raw instead of Cname.value on line 1770 (in version 1.3.3, 
apilevel 2.0), you'll notice it looks like `M\x00Y\x00_\x00C` and so on and so 
forth. 

I was able to patch this by changing

col_name = Cname.value

to 

col_name = Cname.raw.decode().replace('\x00', '')

There may be a better way to fix this, but that one worked for me.

It looks like probably the driver is sending over a slightly wider character 
than pypyodbc is expecting. Not sure if this is a general case on 64-bit 
machines, or just for the iSeries (which would not surprise me)

Original issue reported on code.google.com by wwer...@lwsi.com on 16 Jul 2014 at 9:09

GoogleCodeExporter commented 8 years ago
Looks like that didn't quite fix the issue, as the buffer still contained the 
previous information - I also added (right after that line) 

Cname.value = b'\x00'*1024

I'm quite certain there's a better fix for this issue, but that's the 
workaround I'm using for now.

Original comment by wwer...@lwsi.com on 18 Jul 2014 at 5:40

GoogleCodeExporter commented 8 years ago
I have a very similar issue (see issue 52), using MySQL instead of DB2.

Original comment by marc.van...@gmail.com on 15 Sep 2014 at 11:30

GoogleCodeExporter commented 8 years ago
This patch fixes it. Exactly why, I have no idea because it doesn't look like 
it should be doing anything different. But it does!

Original comment by wwer...@lwsi.com on 20 Nov 2014 at 12:53

Attachments:

GoogleCodeExporter commented 8 years ago
I had the exact same experience too!

My environment is on

    Ubuntu 14.04.2 LTS
    CPython 3.4.0
    TDS version: 4.2
    Microsoft SQL Server 2012 (SP1) - 11

And the above mentioned "0001-Fix-for-issue-45-on-Google-Code.patch" fixes my 
problem.

Original comment by kit...@eac.ne.jp on 19 May 2015 at 7:18