Commits on Jan 13, 2012
Commits on Dec 28, 2011
  1. Issue 178: Fixed compilation issues with 4.6.2

    mkleehammer committed Dec 27, 2011
    Removed deprecated Row_slice.  The sequence structure changed this from an actual function
    pointer to a void pointer.  GCC 4.6.2 would not allow the assignment of Row_slice to void*.
    This may not build under 2.5.
    Also eliminated a bunch of casts to see if newer GCC would uncover other issues.
Commits on Dec 23, 2011
Commits on Dec 18, 2011
Commits on Dec 8, 2011
  1. Python 2 crash when ASCII keyword values passed to connect.

    mkleehammer committed Dec 8, 2011
    MakeConnectionString assumed that values were already converted to Unicode, but this was not
    the case.  Added TextCopyToUnicode to contain the difference which cleans the code up nicely.
    Discovered while trying to reproduce Issue 223.
Commits on Nov 3, 2011
  1. Added FreeTDS unit tests

    mkleehammer committed Nov 3, 2011
Commits on Oct 27, 2011
  1. Issue 170: Fixed memory overwrite when converting Unicode to SQLWCHAR.

    Michael Kleehammer
    Michael Kleehammer committed Oct 27, 2011
    Many thanks to for finding this.
Commits on Oct 17, 2011
  1. fix: Function sequence error with prepared execute, SQLTables, same e…

    Michael Kleehammer
    Michael Kleehammer committed Oct 17, 2011
    The saved prepared statement was not cleaned up when a SQLTables or similar function was used.
    If the next execute used the same SQL, pyodbc did not call SQLPrepare.
Commits on Sep 14, 2011
  1. Issue 145: Update to handle failure.

    mkleehammer committed Sep 14, 2011
    The parameter array is initialized to zero in case of failure during the binding process.
    Therefore it is possible that some values are still zero in FreeInfos.
Commits on Sep 13, 2011
  1. Issue 145: cursor.execute leaks parameters

    Michael Kleehammer
    Michael Kleehammer committed Sep 13, 2011
    Thanks to luke (see issue) for finding, debugging, and providing a fix.
Commits on Aug 21, 2011
  1. Issue 199: with cxn: doesn't commit on success

    mkleehammer committed Aug 21, 2011
    (cherry picked from commit a6b400f)
Commits on Jul 16, 2011
  1. Issue 188: Segfault when fetching NVARCHAR(MAX) data over 511 bytes

    mkleehammer committed Jul 16, 2011
    The provided fix suggestion looks correct and I can see how it would crash, but was unable to
    reproduce with the unit test.  Probably related to Microsoft vs. FreeTDS differences.
Commits on Jul 11, 2011

    mkleehammer committed Jul 11, 2011
    Was passing the incorrect length when binding, causing SQLPut errors when using long strings
    (usually when inserting long strings) for some drivers.
Commits on Jul 8, 2011
Commits on Jul 4, 2011
  1. Issue 186: Added SQLite tests

    mkleehammer committed Jul 4, 2011
    The issue was actually in the ODBC driver, which has been fixed in version
    0.91 of the driver.
    There are a couple of issues left, but I'll need to work through them with the driver author:
    reading a zero-byte blob and reading text values in 2 passes.
Commits on Nov 25, 2010
  1. Fixed printf in new pyodbcconf.

    mkleehammer committed Nov 25, 2010
    Eliminated unused code.
    Eliminated compiler warning.
Commits on Nov 24, 2010
  1. Added pyodbc.drivers() for Windows builds.

    mkleehammer committed Nov 24, 2010
    In the future, I will try to add the method to other platforms by reading the iODBC and
    unixODBC configuration files.
Commits on Nov 23, 2010
Commits on Nov 21, 2010
  1. Issue 121: update with large parameter + no rows updated = error

    mkleehammer committed Nov 21, 2010
    Issue and patch (!) from  Thanks.
  2. Issue 129: ("select ?", None) fails

    mkleehammer committed Nov 21, 2010
    If SQLDescribeParam cannot tell us the type of a column for a NULL parameter, we'll assume it
    is VARCHAR.  We already do this if SQLDescribeParam is not supported.
Commits on Sep 6, 2010
  1. Allocated own string for decimals.

    mkleehammer committed Sep 6, 2010
    Was using str(decimal), but it can return items in exponential notation, which I'm not sure
    many databases would handle properly.