From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:14:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0001.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0001.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0001.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0001.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0002.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0002.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0002.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0002.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 20:02:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 13 20:02:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0003.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0003.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0003.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0003.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 08:02:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0004.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0004.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0004.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0004.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0005.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0005.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0005.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0005.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0006.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0006.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0006.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0006.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 20:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0007.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0007.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0007.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0007.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0008.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0008.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 08:02:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0008.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0008.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:23 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0009.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0009.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0009.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0009.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0010.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 16:00:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0010.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0010.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0010.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0011.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0011.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 20:00:53 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0011.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0011.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:54 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 08:02:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 08:02:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0012.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0012.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0012.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0012.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:47 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0013.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0013.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0013.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0013.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0014.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0014.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0014.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0014.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0015.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0015.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0015.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0015.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0016.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0016.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0016.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0016.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:50 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0017.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0017.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0017.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0017.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0018.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0018.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0018.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0018.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0019.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0019.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 20:01:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0019.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0019.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0020.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0020.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0020.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 08:04:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0020.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 08:04:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0021.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0021.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0021.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0021.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0022.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0022.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0022.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 16:01:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0022.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 16:01:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0023.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0023.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0023.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0023.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 08:04:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0024.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0024.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0024.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0024.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0025.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 12:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0025.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0025.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0025.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0026.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 16:03:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0026.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0026.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0026.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0027.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0027.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0027.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0027.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0028.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0028.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0028.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0028.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:08:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0029.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0029.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0029.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 12:02:33 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 12:02:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0029.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 12:02:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 16:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 16:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 20 16:01:03 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0030.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0030.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0030.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0030.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:01:04 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0031.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0031.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0031.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 20:01:00 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 20 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0031.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 20 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0032.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0032.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0032.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0032.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:04:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0033.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0033.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0033.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0033.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0034.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0034.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0034.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0034.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:01:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0035.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0035.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0035.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0035.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:01:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 08:03:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0036.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:10 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0036.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0036.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0036.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:03:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0037.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0037.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0037.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0037.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:01:03 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0038.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0038.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0038.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0038.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:41 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0039.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0039.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0039.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 20:01:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 22 20:01:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0039.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 22 20:01:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:04 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0040.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0040.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0040.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0040.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:03:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0041.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0041.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0041.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0041.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0042.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0042.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0042.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0042.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:02:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 20:01:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 23 20:01:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0043.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0043.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0043.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0043.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:01:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0044.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0044.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0044.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0044.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 12:03:49 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:49 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 12:03:49 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:49 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 24 12:03:49 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0045.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0045.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0045.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 12:03:50 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 12:03:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0045.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 12:03:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0046.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0046.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0046.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0046.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 16:01:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:46 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0047.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0047.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0047.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0047.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:02:12 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0048.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0048.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0048.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0048.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0049.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0049.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0049.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0049.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0050.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0050.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0050.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0050.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0051.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0051.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0051.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0051.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 08:06:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0052.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0052.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 08:06:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0052.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0052.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:06:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 12:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 12:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0053.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0053.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0053.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0053.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0054.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0054.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0054.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0054.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:01:06 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0055.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0055.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0055.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0055.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 08:07:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 08:07:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 27 08:07:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 08:07:56 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0056.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 08:07:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0056.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0056.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0056.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:57 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 08:07:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:07:58 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0057.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0057.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0057.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0057.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0058.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0058.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0058.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0058.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 20:01:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Jan 27 20:01:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0059.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0059.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0059.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0059.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:01:13 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 08:06:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 08:06:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 28 08:06:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0060.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0060.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0060.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 08:06:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0060.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 08:06:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:06:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 12:02:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 12:02:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 28 12:02:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0061.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0061.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0061.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0061.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:02:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0062.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0062.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0062.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0062.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:01:08 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0063.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0063.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0063.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0063.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0064.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0064.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0064.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0064.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:59 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0065.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0065.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0065.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0065.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0066.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0066.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0066.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0066.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:01:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0067.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0067.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0067.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0067.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:01:09 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 08:10:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:10:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 08:10:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:10:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 30 08:10:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:10:56 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0068.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0068.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0068.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 08:11:04 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 08:11:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0068.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:11:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 08:11:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:11:06 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0069.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0069.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0069.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 12:04:34 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 12:04:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0069.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 12:04:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:04:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 16:04:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 16:04:45 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 30 16:04:46 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:46 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 16:04:47 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0070.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 16:04:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0070.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0070.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0070.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:39 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0071.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0071.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0071.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0071.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:40 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:43 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 08:08:44 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0072.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:44 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0072.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0072.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0072.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:08:45 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:54 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 12:04:55 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0073.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 12:04:55 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0073.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0073.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0073.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 16:02:48 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0074.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 16:02:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0074.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0074.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0074.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0075.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0075.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0075.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Jan 31 20:01:23 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0075.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Jan 31 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 08:11:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 08:11:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 1 08:11:04 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:04 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 08:11:05 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0076.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 08:11:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 08:11:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0076.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0076.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0076.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:11:07 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:12 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 12:03:13 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0077.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 12:03:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 12:03:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0077.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 12:03:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0077.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0077.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:03:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0078.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0078.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0078.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0078.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0079.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0079.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0079.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0079.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:10 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 08:15:16 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0080.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 08:15:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 08:15:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0080.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 08:15:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0080.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:17 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 08:15:17 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 08:15:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0080.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 08:15:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:15:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0081.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0081.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0081.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 12:03:23 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0081.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0082.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0082.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0082.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0082.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0083.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0083.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0083.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 20:01:19 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 2 20:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0083.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 2 20:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:20 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0084.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0084.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0084.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:27 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 08:14:28 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 08:14:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0084.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 08:14:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:14:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:16 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 12:03:17 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0085.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0085.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0085.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0085.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:03:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0086.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0086.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0086.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0086.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0087.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0087.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0087.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0087.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 08:09:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 08:09:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 4 08:09:46 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 08:09:49 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0088.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:49 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 08:09:49 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 08:09:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0088.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 08:09:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0088.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:50 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 08:09:50 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 08:09:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0088.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 08:09:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:09:51 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0089.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0089.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0089.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0089.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0090.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0090.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0090.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0090.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0091.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0091.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0091.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0091.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:22 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 08:08:29 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0092.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 08:08:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0092.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0092.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0092.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:08:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:15 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 12:03:16 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0093.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 12:03:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0093.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0093.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0093.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:03:17 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0094.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0094.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0094.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0094.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0095.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 20:01:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0095.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0095.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0095.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 08:17:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 08:17:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 6 08:17:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:34 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 08:17:39 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0096.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:39 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 08:17:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 08:17:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0096.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 08:17:40 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0096.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:41 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 08:17:41 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 08:17:42 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0096.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:42 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 08:17:42 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:17:42 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0097.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0097.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0097.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0097.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:03:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0098.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 16:01:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0098.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0098.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0098.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0099.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0099.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0099.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0099.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 08:27:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:27:57 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 08:27:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:27:58 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 7 08:27:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:27:58 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 08:28:17 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0100.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:28:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 08:28:17 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 08:28:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0100.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 08:28:20 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0100.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:28:20 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 08:28:20 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 08:28:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0100.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:28:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 08:28:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:28:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 12:03:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 12:03:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:54 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 7 12:03:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:55 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 12:03:59 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0101.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 12:03:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 12:03:59 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0101.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0101.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0101.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:04:00 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0102.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0102.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0102.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 16:01:30 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0102.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0103.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0103.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0103.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0103.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 08:27:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 08:27:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 8 08:27:03 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:03 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 08:27:13 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0104.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 08:27:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 08:27:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0104.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 08:27:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0104.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:15 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 08:27:15 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 08:27:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0104.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 08:27:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:27:16 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 12:04:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 12:04:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 8 12:04:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0105.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0105.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0105.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 12:04:10 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 12:04:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0105.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 12:04:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:04:11 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0106.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0106.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0106.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0106.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0107.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0107.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0107.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0107.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:32 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 08:10:33 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0108.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 08:10:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 08:10:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0108.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 08:10:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0108.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:34 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 08:10:34 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 08:10:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0108.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 08:10:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:10:35 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:52 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0109.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0109.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0109.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 12:03:54 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 12:03:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0109.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 12:03:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:55 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:35 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0110.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0110.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0110.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0110.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:36 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0111.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0111.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0111.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0111.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:32 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 08:26:35 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:26:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 08:26:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:26:36 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 10 08:26:36 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:26:39 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 08:27:10 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0112.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:27:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 08:27:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 08:27:13 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0112.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 08:27:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0112.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:27:15 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 08:27:15 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 08:27:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0112.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:27:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 08:27:18 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:27:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:23 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0113.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0113.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0113.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 12:04:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0113.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 12:04:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:04:26 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0114.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0114.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0114.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0114.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:29 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 20:01:26 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:27 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Feb 10 20:01:27 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:27 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Feb 10 20:01:27 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:27 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 20:01:29 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0115.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 20:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Feb 10 20:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0115.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 20:01:29 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0115.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0115.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 08:14:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 08:14:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 11 08:14:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 08:14:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0116.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 08:14:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 08:14:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0116.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 08:14:26 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0116.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:26 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 08:14:26 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 08:14:27 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0116.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:27 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 08:14:27 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:14:27 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:17 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0117.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0117.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0117.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:18 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 12:03:19 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0117.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:03:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0118.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0118.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0118.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0118.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:24 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0119.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0119.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0119.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0119.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:15 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:50 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 08:10:51 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0120.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 08:10:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0120.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0120.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0120.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:10:52 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:22 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 12:03:24 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0121.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 12:03:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0121.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0121.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0121.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:03:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0122.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0122.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0122.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0122.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0123.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0123.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0123.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0123.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:21 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 08:20:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 08:20:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:07 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 13 08:20:07 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 08:20:14 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0124.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 08:20:14 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 08:20:15 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0124.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 08:20:16 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0124.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:16 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 08:20:16 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 08:20:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0124.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 08:20:19 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:20:20 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 12:03:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 12:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 13 12:03:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 12:03:48 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0125.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 12:03:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 12:03:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0125.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0125.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0125.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:49 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0126.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 16:01:47 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0126.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0126.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0126.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:48 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Mon Feb 13 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:25 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Mon Feb 13 20:01:25 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:27 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0127.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0127.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0127.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0127.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:28 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 08:22:05 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0128.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 08:22:05 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 08:22:08 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0128.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 08:22:11 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0128.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:11 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 08:22:11 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 08:22:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0128.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 08:22:14 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:22:15 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:02 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0129.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0129.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0129.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 12:04:04 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 12:04:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0129.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 12:04:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:04:05 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0130.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0130.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0130.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0130.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 16:02:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:02:02 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0131.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0131.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0131.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0131.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:31 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 08:34:03 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 08:34:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:04 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 15 08:34:05 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:05 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 08:34:18 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0132.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 08:34:18 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 08:34:19 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0132.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 08:34:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0132.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:23 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 08:34:23 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 08:34:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0132.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 08:34:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:34:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 12:06:18 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 12:06:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:19 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 15 12:06:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:19 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 12:06:23 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0133.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 12:06:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 12:06:23 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0133.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 12:06:24 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0133.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:24 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 12:06:24 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 12:06:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0133.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 12:06:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:06:25 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 16:01:55 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0134.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0134.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0134.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0134.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:56 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0135.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 19:28:33 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0135.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0135.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0135.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:34 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 20:15:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Wed Feb 15 20:15:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:46 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Wed Feb 15 20:15:46 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:47 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 20:15:49 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0136.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 20:15:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Wed Feb 15 20:15:50 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0136.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 20:15:51 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0136.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:51 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 20:15:51 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Wed Feb 15 20:15:53 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0136.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:53 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Wed Feb 15 20:15:53 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:15:53 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 16 08:51:05 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:51:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Thu Feb 16 08:51:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:51:08 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Thu Feb 16 08:51:08 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:51:09 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 16 08:51:27 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0137.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:51:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 16 08:51:27 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Thu Feb 16 08:51:32 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0137.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 16 08:51:38 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0137.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:51:38 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 16 08:51:38 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Thu Feb 16 08:52:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0137.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:52:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Thu Feb 16 08:52:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:52:01 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 14:37:34 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions Message-ID: 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 ------------------------------>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)) From mal at egenix.com Tue Dec 6 15:44:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: Message-ID: <4395B1F0.5010006@egenix.com> Hello Enrico, enrico.sirola@gmail.com wrote: > 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). Right: unfortunately, ODBC 3.52 introduced an incompatible change in the way certain lengths are handled which show up on 64-bit platforms. Version 2.0.x of mxODBC is not 64-bit ODBC compatible. However, we do have a version 2.1 of mxODBC which is 64-bit compatible (this is the version used in our mxODBC Zope DA product). If you want to give it a try, we can send you the download link for the binary and an evaluation copy. > 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. Thanks, but this is not a complete patch set - it's likely that you'll get core dumps or at least wrong results with this minimal set of changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From enrico.sirola at gmail.com Tue Dec 6 16:58:09 2005 From: enrico.sirola at gmail.com (enrico.sirola@gmail.com) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: <4395B1F0.5010006@egenix.com> References: <4395B1F0.5010006@egenix.com> Message-ID: Hi Marc-Andre, >>>>> "Marc-Andre" == M -A Lemburg writes: Marc-Andre> enrico.sirola@gmail.com wrote: >> 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). Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an Marc-Andre> incompatible change in the way certain lengths are Marc-Andre> handled which show up on 64-bit platforms. Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC Marc-Andre> compatible. However, we do have a version 2.1 of Marc-Andre> mxODBC which is 64-bit compatible (this is the version Marc-Andre> used in our mxODBC Zope DA product). Marc-Andre> If you want to give it a try, we can send you the Marc-Andre> download link for the binary and an evaluation copy. I would be interested in trying an evaluation copy, even if I don't use the Zope adapter. Can you please send me a copy/evaluation license? Btw, are you going to release the new mxODBC to the public, like you did with the 2.* versions? >> 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. Marc-Andre> Thanks, but this is not a complete patch set - it's Marc-Andre> likely that you'll get core dumps or at least wrong Marc-Andre> results with this minimal set of changes. Hmmm it seems you confirm my suspects :-) Ok thanks a lot, enrico -- Enrico Sirola From mal at egenix.com Tue Dec 6 20:36:45 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] mxODBC on x86_64 - strange integer conversions In-Reply-To: References: <4395B1F0.5010006@egenix.com> Message-ID: <4395F65A.90004@egenix.com> enrico.sirola@gmail.com wrote: > Hi Marc-Andre, > > >>>>>>"Marc-Andre" == M -A Lemburg writes: > > > Marc-Andre> enrico.sirola@gmail.com wrote: > >> 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). > Marc-Andre> Right: unfortunately, ODBC 3.52 introduced an > Marc-Andre> incompatible change in the way certain lengths are > Marc-Andre> handled which show up on 64-bit platforms. > Marc-Andre> Version 2.0.x of mxODBC is not 64-bit ODBC > Marc-Andre> compatible. However, we do have a version 2.1 of > Marc-Andre> mxODBC which is 64-bit compatible (this is the version > Marc-Andre> used in our mxODBC Zope DA product). > Marc-Andre> If you want to give it a try, we can send you the > Marc-Andre> download link for the binary and an evaluation copy. > > I would be interested in trying an evaluation copy, even if I don't > use the Zope adapter. Can you please send me a copy/evaluation > license? Will do. > Btw, are you going to release the new mxODBC to the public, > like you did with the 2.* versions? We are going to release it as separate product, yes, but the standard version is probably not going to include source code. > >> 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. > Marc-Andre> Thanks, but this is not a complete patch set - it's > Marc-Andre> likely that you'll get core dumps or at least wrong > Marc-Andre> results with this minimal set of changes. > > Hmmm it seems you confirm my suspects :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Dierk.Hoeppner at tib.uni-hannover.de Tue Dec 13 07:28:59 2005 From: Dierk.Hoeppner at tib.uni-hannover.de (=?iso-8859-1?Q?=22H=F6ppner=2C_Dierk=22?=) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze Message-ID: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Hello, I wanted to use BeeDict on Windows. But in Lib file FileLock.py in SymbolicFileLock.lock() you find on line 116 makelink=os.symlink symlink() is only available on *nixes. Any suggestions how to circumvent this? Greetings Dierk ---- Dipl.-Ing. Dierk H?ppner German National Library of Science and Technology University Library Hannover IT Department Coordination Software Projects Welfengarten 1B 30167 Hannover Germany Tel.: +49 (0) 511/762-4067 Mobile: +49 (0) 631/7624067 Fax.: +49 (0) 511/762-5881 From mal at egenix.com Tue Dec 13 10:01:09 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:30 2006 Subject: [egenix-users] BeeDict-Problem on Windoze In-Reply-To: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> References: <8846902319690F49AE6DAC02B2F7551F330BCB@nts3040.tib.uni-hannover.de> Message-ID: <439E9BE3.6040306@egenix.com> H?ppner, Dierk wrote: > Hello, > > I wanted to use BeeDict on Windows. But in Lib file FileLock.py in > SymbolicFileLock.lock() you find on line 116 > > makelink=os.symlink > > symlink() is only available on *nixes. Any suggestions how to circumvent > this? The 2.1 pre-release of egenix-mx-base has a version of FileLock.py which also works on Windows. Our most recent snapshot: http://www.egenix.com/files/python/egenix-mx-base-2.1.0-2005-05-01.zip -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From holtwick at spirito.de Mon Dec 19 14:53:11 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Mar 31 16:34:35 2006 Subject: [egenix-users] cmp() function Message-ID: <43A6C954.9000608@spirito.de> Hi, in mx.DateTime there is a function called "cmp". Described like this in the documentation: "... There is a special compare function included (cmp()) in the package that allows you to compare two date/time values using a given accuracy, e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to compare equal." I think this function conflicts with the system function cmp() used e.g. by sort() if you import DateTime like this: from mx.DateTime import * Would'nt it be better to name it "datecmp" or similar or a least implement a fallback to the system cmp function instead of raising an exception? Bye, Dirk Holtwick =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= spirito GmbH Dirk Holtwick Gr?nstra?e 6 D-47051 Duisburg mbx: holtwick@spirito.de web: http://www.spirito.de -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/1cea9010/holtwick-0138.vcf From mal at egenix.com Mon Dec 19 15:02:19 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6C954.9000608@spirito.de> References: <43A6C954.9000608@spirito.de> Message-ID: <43A6CB79.9050302@egenix.com> Dirk Holtwick wrote: > Hi, > > in mx.DateTime there is a function called "cmp". Described like this in > the documentation: > > "... There is a special compare function included (cmp()) in the package > that allows you to compare two date/time values using a given accuracy, > e.g. cmp(date1,date2,0.5) will allow 12:00:00.5 and 12:00:01.0 to > compare equal." > > I think this function conflicts with the system function cmp() used e.g. > by sort() if you import DateTime like this: > > from mx.DateTime import * > > Would'nt it be better to name it "datecmp" or similar or a least > implement a fallback to the system cmp function instead of raising an > exception? No. In fact, the cmp() function was named deliberately after the builtin one. Falling back to the system one would only hide a programming error. In summary: You should never do "from mx.DateTime import *" - that's bad style :-) I tend to always write: from mx import DateTime ... d = DateTime.now() Makes reading the code a lot easier too, esp. if you regularly work with or on large frameworks -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 19 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From charlie at egenix.com Mon Dec 19 15:09:37 2005 From: charlie at egenix.com (Charlie Clark) Date: Fri Mar 31 16:34:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <20051219160939.43931.13@Zeta.1134984427.fake> On 2005-12-19 at 16:02:17 [+0100], M.-A. Lemburg wrote: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Python explicitly allows and to some extent encourages this style. Wrapping things up in namespaces should avoid most errors. > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) I agree with this. I remember reading at one point that import * was to be made illegal in Python. The documentation should be updated to reflect this! > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Correct use of namespaces is one of the greatest things in Python. With "as" allowing redesignation as required. Charlie From holtwick at spirito.de Mon Dec 19 16:00:21 2005 From: holtwick at spirito.de (Dirk Holtwick) Date: Fri Mar 31 16:34:35 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6CB79.9050302@egenix.com> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> Message-ID: <43A6D911.40907@spirito.de> M.-A. Lemburg schrieb: > No. In fact, the cmp() function was named deliberately after > the builtin one. Falling back to the system one would only > hide a programming error. Well, finding such a programming error is hard. I didn't expect DateTime to override the cmp() function and was quite irritated when I tried to implement an own sorting algorithm. Now that I know it, I can live with this function ;-) > In summary: You should never do "from mx.DateTime import *" - > that's bad style :-) > > I tend to always write: > > from mx import DateTime > ... > d = DateTime.now() > > Makes reading the code a lot easier too, esp. if you regularly > work with or on large frameworks Okay, looks nicer and is more expressive. I agree. But I like the "bad style" too and as far as I know it is still allowed ;-) Bye, Dirk -------------- next part -------------- A non-text attachment was scrubbed... Name: holtwick.vcf Type: text/x-vcard Size: 304 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20051219/5384a20e/holtwick-0138.vcf From moof at metamoof.net Mon Dec 19 16:23:52 2005 From: moof at metamoof.net (Moof) Date: Fri Mar 31 16:34:36 2006 Subject: [egenix-users] cmp() function In-Reply-To: <43A6D911.40907@spirito.de> References: <43A6C954.9000608@spirito.de> <43A6CB79.9050302@egenix.com> <43A6D911.40907@spirito.de> Message-ID: On 12/19/05, Dirk Holtwick wrote: > > > In summary: You should never do "from mx.DateTime import *" - > > that's bad style :-) > > Okay, looks nicer and is more expressive. I agree. But I like the "bad > style" too and as far as I know it is still allowed ;-) > > >From "The Tao of Python" ("import this"): Explicit is better than implicit Namespaces are one honking great idea -- let's do more of those! Anyway, yeah, the solution I tend to do is rather than: >>> from mx.DateTime import * I explicitly import the things I want to use, thus making sure I don't pollute my namespace too much. At the top of many of my files you will see: >>> from mx.DateTime import Date, oneDay which means I keep track of what I'm putting into my namespace. My current coding conventions do actually disallow "import *", and invariably I find I have much less in the way of problems in my code this way. Of course, when prototyping in the interactive shell, I sometimes resort to import *, but most of the time even there I only import what I need. Incidentally, you can get to the built-in cmp function by explicitly calling __builtins__.cmp Moof -- giving this gmail lark a try -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051219/930e3df6/attachment-0138.htm From mal at egenix.com Fri Dec 23 13:15:03 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:36 2006 Subject: [egenix-users] Season's Greetings Message-ID: <43ABF855.3040203@egenix.com> Dear eGenix Users, I'd like to wish you all a Merry Christmas and Happy New Year. The past year has been a very interesting one for eGenix: we've had several new releases of the mxODBC Zope DA and the response from you, the users, has been very positive. For next year, we are planning a few new product launches that will make the Python, Zope and Plone database experience an even better one, with support for more database backends and solutions for common client-server situations. Thank you and enjoy the holidays, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 23 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 11:11:12 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Mar 31 16:34:36 2006 Subject: [egenix-users] Unicode problem Message-ID: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> I'm in the process of adding Microsoft SQL Server support to MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. I've bought a copy of mxODBC Zope DA. Unfortunately I keep getting a "TypeError: command must be a string". Doing some quick Googling suggested this was a Unicode problem and when I changed the input to ordinary strings it works fine. Obviously we could get MailManager to check if it is using the mxODBC and then avoid Unicode if it is but that would be quite a lot of work and something I'm keen to avoid if there is a work around. Thanks in advance Andrew -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From moof at metamoof.net Thu Dec 29 12:05:07 2005 From: moof at metamoof.net (Moof) Date: Fri Mar 31 16:34:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: On 12/29/05, Andrew Veitch wrote: > > I'm in the process of adding Microsoft SQL Server support to > MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. > I've bought a copy of mxODBC Zope DA. > > Unfortunately I keep getting a "TypeError: command must be a string". > Doing some quick Googling suggested this was a Unicode problem and > when I changed the input to ordinary strings it works fine. > > Obviously we could get MailManager to check if it is using the mxODBC > and then avoid Unicode if it is but that would be quite a lot of work > and something I'm keen to avoid if there is a work around. It's a bit of an ambiguous error message. The command must be a string, this seems to be a limitation of mxODBC. However, the values in a prepared statement can be unicode if necessary, and mXODBC handles that situation correctly. This is wrong and raises the above error: cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") This works: cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) ...and also gives you the advantage of doing all your escaping for you, all the better to avoid SQL injection attacks, as well as caching execution paths for complex queries. Yes, it's annoying, as most ORM packages these days seem to generate unicode strings, which makes mxODBC of limited use with them. I'm not sure if this is a limitation of ODBC itself, but if it isn't, is there any chance of getting mxODBC working with these strings? Moof -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20051229/716010b5/attachment-0138.htm From mal at egenix.com Thu Dec 29 12:40:56 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> Message-ID: <43B3D955.5090507@egenix.com> Moof wrote: > On 12/29/05, Andrew Veitch wrote: >> I'm in the process of adding Microsoft SQL Server support to >> MailManager. Currently it supports PostgreSQL (psycopg) and MySQL. >> I've bought a copy of mxODBC Zope DA. >> >> Unfortunately I keep getting a "TypeError: command must be a string". >> Doing some quick Googling suggested this was a Unicode problem and >> when I changed the input to ordinary strings it works fine. >> >> Obviously we could get MailManager to check if it is using the mxODBC >> and then avoid Unicode if it is but that would be quite a lot of work >> and something I'm keen to avoid if there is a work around. > > > It's a bit of an ambiguous error message. > > The command must be a string, this seems to be a limitation of mxODBC. > However, the values in a prepared statement can be unicode if necessary, and > mXODBC handles that situation correctly. > > This is wrong and raises the above error: > > cursor.execute(u"INSERT INTO table1 (value1) VALUES '?????'") > > This works: > > cursor.execute('INSERT INTO table1 (value1) VALUES ?', (u'?????',)) > > ...and also gives you the advantage of doing all your escaping for you, all > the better to avoid SQL injection attacks, as well as caching execution > paths for complex queries. Indeed. Unfortunately, the Zope database architecture currently doesn't support passing parameters to the SQL command - it insists on inlining everything into the command string which has several limitations: not only the problem of having to do the escaping and the risk of SQL injection, but also the rather simple problem of the command string length being limited by several database backends. In Zope, the only work-around is to do queries using external methods which can then use the bound parameter strategy. Note that this is supported by the mxODBC Zope DA (please see the documentation). It is true that the command string currently cannot be Unicode. The reason for this is that the ODBC API for passing in the command string does not support Unicode. There is a special Unicode API in ODBC for this, but support among drivers is only starting to get to a state where this API would be a viable choice for mxODBC. > Yes, it's annoying, as most ORM packages these days seem to generate unicode > strings, which makes mxODBC of limited use with them. I'm not sure if this > is a limitation of ODBC itself, but if it isn't, is there any chance of > getting mxODBC working with these strings? The next release of the mxODBC Zope DA will support encodings to work around this problem. You will be able to specify the database encoding to use and the Zope DA will then automatically convert Unicode to this encoding prior to passing it to the database driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 29 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andrew at logicalware.com Thu Dec 29 13:33:11 2005 From: andrew at logicalware.com (Andrew Veitch) Date: Fri Mar 31 16:34:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <43B3D955.5090507@egenix.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> Message-ID: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > The next release of the mxODBC Zope DA will support encodings > to work around this problem. You will be able to specify > the database encoding to use and the Zope DA will then > automatically convert Unicode to this encoding prior > to passing it to the database driver. That would be perfect. Do you have a date for the release planned? A -- Logicalware Ltd Stuart House, Eskmills, Musselburgh, EH21 7PQ, UK Tel: +44(0)131 273 5130 http://www.logicalware.com From mal at egenix.com Fri Dec 30 14:12:37 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:34:37 2006 Subject: [egenix-users] Unicode problem In-Reply-To: <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> References: <60308271-FF4B-4912-B512-35CE6B6AA08B@logicalware.com> <43B3D955.5090507@egenix.com> <334AA61A-5E6A-4866-8FE2-C371DA34E690@logicalware.com> Message-ID: <43B53245.8060103@egenix.com> Andrew Veitch wrote: > On 29 Dec 2005, at 12:40, M.-A. Lemburg wrote: > >> The next release of the mxODBC Zope DA will support encodings >> to work around this problem. You will be able to specify >> the database encoding to use and the Zope DA will then >> automatically convert Unicode to this encoding prior >> to passing it to the database driver. > > That would be perfect. > > Do you have a date for the release planned? Not yet, sorry. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::