Bug 492802

Summary: Simple string parameter binding fails
Product: [Fedora] Fedora EPEL Reporter: Troels Arvin <troels>
Component: pymssqlAssignee: Ray Van Dolson <rayvd>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: el5CC: rayvd
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-13 22:21:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.