Fixes #43. unixODBC does not define the SQLWCHAR type to match its requirements (2-byte chars), so I can't rely on it. I've added ODBCCHAR. At this time it is hardcoded to 2-bytes which works for Windows and unixODBC. I need to add a mechanism to override this. Tested on OS X postgres, Ubuntu 14 64-bix postgres, and Windows 7 64-bit SQL Server.
…from VARCHAR 65000 fields.
Some drivers have problems with the LEN version, so eliminating use when possible. There is an ODBC GetInfo query to determine if LEN is required. Upon connection, this is cached and LEN is used if this is 'y'. FreeTDS, for example, requires LEN in some cases.
Cursor objects can now be used in "with" statements and will automatically commit the transaction if successful. This is part of the effort to allow programs to be written using only Cursors. There are times when having separate connections and cursors are necessary, but very rare. By duplicating connection functionality in the cursor, most programs can probably use a single Cursor object everywhere.
…xecute. (Lost fix) This was fixed in 2.1.12 and lost during the Python 3 conversion. 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. (cherry picked from commit 7fdec2f)
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.
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.
Many thanks to davidp.r...@gmail.com for finding this.