Bug 492802 - Simple string parameter binding fails
Simple string parameter binding fails
Product: Fedora EPEL
Classification: Fedora
Component: pymssql (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Ray Van Dolson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-29 15:38 EDT by Troels Arvin
Modified: 2009-04-13 18:21 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-13 18:21:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Troels Arvin 2009-03-29 15:38:09 EDT
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):

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'))

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()

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 18:15:49 EDT
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 18:41:07 EDT
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 18:11:53 EDT
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.