[egenix-users] mxODBC on x86_64 - strange integer conversions

[enrico.sirola at gmail.com]

Hello,
I'm trying to use mxODBC on an x86_64, with unixODBC 2.2.12 and
easysoft's odbc-odbc bridge client to connect to a MS SQL Server with
python. The version of mxODBC I'm using is 2.0.7, and I get weird
results from the select queries on integer fields (i.e. huge
numbers), while isql works quite nicely. This seems related to the
int/long size differences on the x86_64 platform (the 1st being 4, the
2nd 8). I digged a bit the code, and it seems the following patch
solves the problem (anyway I didn't have the time to test it very
well) (apply it from the root of egenix-commercial with patch -p0).
Please let me know your thoughts.
Bye,
e.


-- 
Enrico Sirola <enrico.sirola at gmail.com>

------------------------------>cut here<------------------------------

--- mx/ODBC/unixODBC/mxODBC.c	2005-12-06 15:07:52.380087793 +0100
+++ mx/ODBC/unixODBC/mxODBC.c.new	2005-12-06 15:03:33.646393920 +0100
@@ -1256,7 +1256,7 @@
 PyObject *mxODBC_IntFromLong(mxODBCursorObject *dbcs,
 			     mxODBCursor_Variable *var)
 {
-    return PyInt_FromLong(*(long *)var->data);
+    return PyInt_FromLong(*(SQLINTEGER *)var->data);
 }
 
 /* Python float from C double. */
@@ -1490,7 +1490,7 @@
     int size;
 
     DPRINTF("mxODBC_StringFromObject: called for object %s at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     /* Special case for DateTimeDelta instances: */
     if (mxDateTimeDelta_Check(v)) {
@@ -1603,7 +1603,7 @@
 			    mxODBCursor_Variable *var)
 {
     DPRINTF("mxODBC_BinaryFromObject: called for object %s at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     /* Do the same conversion as for string data and then set the type
        to SQL_C_BINARY. */
@@ -1629,7 +1629,7 @@
     int size;
 
     DPRINTF("mxODBC_StringFromLongObject: called for object %s at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     Py_Assert(PyLong_Check(v),
 	      PyExc_TypeError,
@@ -1681,7 +1681,7 @@
     PyObject *s = 0;
 
     DPRINTF("mxODBC_WideCharFromObject: called for %s object at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     /* Convert v to Unicode object s */
     if (PyUnicode_Check(v)) {
@@ -1782,7 +1782,7 @@
     PyObject *w = 0;
 
     DPRINTF("mxODBC_LongFromObject: called for object %s at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     if (PyString_Check(v)) {
 	char *end;
@@ -1843,7 +1843,7 @@
     PyObject *w = 0;
 
     DPRINTF("mxODBC_DoubleFromObject: called for object %s at 0x%x\n",
-	    v->ob_type->tp_name,(int)v);
+	    v->ob_type->tp_name,(long)v);
 
     if (PyString_Check(v)) {
 	char *end;
@@ -2423,7 +2423,7 @@
 {
     DPRINTF("mxODBCursor_SetConverter: "
 	    "called for cursor at 0x%0x, converter=0x%0x\n",
-	    (int)dbcs,(int)converter);
+	    (long)dbcs,(long)converter);
     if (dbcs->converter == converter)
 	return 0;
     if (converter)
@@ -2938,7 +2938,7 @@
 	       decimals) and not the storage size.
 	       
 	    */
-	    var->data_len = sizeof(long);
+	    var->data_len = sizeof(SQLINTEGER);
 	    var->data_buflen = var->data_len;
 	    data = (SQLPOINTER)new(char,var->data_buflen);
 	    if (!data) {
@@ -6877,7 +6877,7 @@
     mxODBC_SQLCheck(henv,SQL_NULL_HDBC,SQL_NULL_HSTMT);
     
     DPRINTF("initmxODBC:  henv=0x%0x\n",
-	    (int)henv);
+	    (long)henv);
 
     /* Register cleanup function */
     if (Py_AtExit(mxODBCModule_Cleanup))