Bug 492802 - Simple string parameter binding fails
Summary: Simple string parameter binding fails
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: pymssql
Version: el5
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Ray Van Dolson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-29 19:38 UTC by Troels Arvin
Modified: 2009-04-13 22:21 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-13 22:21:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Troels Arvin 2009-03-29 19:38:09 UTC
Description of problem:
Using code from the pymssql user guide fails when a string parameter binding is involved.

Version-Release number of selected component (if applicable):
0.8.0-2.el5

How reproducible: 100%

Steps to Reproduce:
Create a database table like this:
CREATE TABLE persons(id INT,fullname VARCHAR(200))

Now, try running code like this:
#=====================================================================
#!/usr/bin/env python

import pymssql

conn = pymssql.connect(host='h', user='u', password='p',database='d')
cur = conn.cursor()
cur.execute('INSERT INTO persons VALUES(%d, %s)',(5,'John Doe'))
conn.commit()

cur.execute('SELECT * FROM persons WHERE fullname=%s','John Doe')
row = cur.fetchone()
while row:
    print "ID=%d, Name=%s" % (row[0], row[1])
    row = cur.fetchone()

conn.close()
#=====================================================================
 
Actual results:
The script returns an error:
Traceback (most recent call last):
  File "./pymssql-test.py", line 11, in ?
    cur.execute('SELECT * FROM persons WHERE fullname=%s','John Doe')
  File "/usr/lib64/python2.4/site-packages/pymssql.py", line 126, in execute
    self.executemany(operation, (params,))
  File "/usr/lib64/python2.4/site-packages/pymssql.py", line 152, in executemany
    raise DatabaseError, "internal error: %s" % self.__source.errmsg()
pymssql.DatabaseError: internal error: None

Expected results:
ID=5, Name=John Doe

Additional info:
I tried recompiling the package using the latest upstream version (1.0.1), and now things work as expected. The recompilation was very straight forward, except that the spec file's %doc-line needed to be changed to this:
%doc README ChangeLog TODO lgpl.txt

By the way, the description of the package starts with this sentence:
   An "almost" DB-API 2.0 compliant module for access 
   to Microsoft SQL servers from Python.
The project page at http://pymssql.sourceforge.net/ doesn't mention any non-compliance. Maybe the description needs to be changed, if the latest source code (1.0.1) for the package is used.

Comment 1 Ray Van Dolson 2009-03-29 22:15:49 UTC
So I'll consider this an upgrade the package request. :-)  Will have to see what kind of changes we're looking at going to the latest release... "almost rewritten from scratch" makes me think we could be looking at some ABI changes, but we'll see (even if they only make things fully DB-API 2.0 compliant).

Comment 2 Ray Van Dolson 2009-03-29 22:41:07 UTC
It looks like this should be a fairly safe upgrade with the only warnings being for people using _mssql directly.  I'll get something built and make a note here when it's in -testing.

Comment 3 Ray Van Dolson 2009-04-09 22:11:53 UTC
This should be in epel-testing tonight.  Keep in mind that if you were using _mssql, you'll need to update your scripts.  The higher level API should have stayed the same.

There were some delays getting this pushed due to some python-related issues with plague, the package build system for EPEL.


Note You need to log in before you can comment on or make changes to this bug.